From owner-freebsd-current@freebsd.org Fri Jul 10 23:21:15 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 460FA3760E7 for ; Fri, 10 Jul 2020 23:21:15 +0000 (UTC) (envelope-from yuripv@yuripv.dev) Received: from wnew2-smtp.messagingengine.com (wnew2-smtp.messagingengine.com [64.147.123.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B3TZ24YZWz44vM; Fri, 10 Jul 2020 23:21:14 +0000 (UTC) (envelope-from yuripv@yuripv.dev) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.west.internal (Postfix) with ESMTP id 86BCD1266; Fri, 10 Jul 2020 19:12:38 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Fri, 10 Jul 2020 19:12:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuripv.dev; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm1; bh=vW1pAnlpbL22lfYL9fvHguITb1Q paIKnxap/Jq6Op1M=; b=lZxCkh66YpAaGZCOCbpzvf2RogHOVcBQMsl2rTggIct U+1H6E4Eyzs9LBuCRSw9DT1KIe15JSv8USFni6hE2Wk8P8lzNXzH6DeT24eCKj0f k+2Ol/Vpcat0vI1tiq2duVpq2fFCw5PiTJEEFNtBn7+mECvGcpP6VpSGk+y35329 wTyY5/GZMFnMSXKJuBiRFeLg5oQRnpuxIIJP2c90OYGsZiKmvNhqgMhz+UUt2FKo qOJu1+5+ivRbH9IhtSBSRk4Q/ZU0ImO4wN/mllAMTOPKNElXBuAXPHzUG1/HGDnE DJbTBZLnW82qrOISY7T0pACsfeXQQWhrXGXrU0g9DjQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=vW1pAn lpbL22lfYL9fvHguITb1QpaIKnxap/Jq6Op1M=; b=OLT/poFNMEHpidbJCBSs/B KjuwhXWRdoSkqqqJIf67i4TNtJJ7ns+mVIvxSz+F0AgqObdFhtDLSu988Wb1INMG //WYc6kDdw6MmbLK70zGEmO3XBPYnd1SEa7zQXoUanTabimPHDRHK36bSTSUGUfL oOJ/657gtzdjfDCbXSesztx0GHnMgf6dzcAvDwbspfweNoaRxbGsA9AzA0akKIDS ZmdyQcilueCjGgO5cwLleobxkl7COAuEESwnWP7NFJjwydh+yQApZfgPzZNv/f3h H/KBmNupLbATCTYM3IoJPBLUfIUMpUP2zvhJXT86R/EfwXdcv8JAkX2nMSYOXFuw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrvddvgddvtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhffkffgfgggjtgesmhdtreertdefjeenucfhrhhomhepjghurhhiucfr rghnkhhovhcuoeihuhhrihhpvheshihurhhiphhvrdguvghvqeenucggtffrrghtthgvrh hnpedvheefjedvheelfeegveduteelkeetgeeggeetuddttdefieekvdekvdetudfftden ucffohhmrghinhepfhhrvggvsghsugdrohhrghdpihhmghhurhdrtghomhenucfkpheple durddvgedtrdduvdegrddufeejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm pehmrghilhhfrhhomhephihurhhiphhvseihuhhrihhpvhdruggvvh X-ME-Proxy: Received: from [192.168.1.6] (unknown [91.240.124.137]) by mail.messagingengine.com (Postfix) with ESMTPA id 9B8F5306005F; Fri, 10 Jul 2020 19:12:36 -0400 (EDT) Subject: Re: svn commit: r352558 - head/usr.bin/top To: Mark Millard Cc: Steve Wills , "daichi@freebsd.org" , FreeBSD Current , Hiroki Sato References: <1BDFB387-930D-4F4D-8729-A5850F1C15B9.ref@yahoo.com> <1BDFB387-930D-4F4D-8729-A5850F1C15B9@yahoo.com> <61107ecc-6f9b-a4db-7b1e-ec75f73939ee@FreeBSD.org> From: Yuri Pankov Message-ID: Date: Sat, 11 Jul 2020 02:12:35 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------B7B098E381178D7AA584F23E" Content-Language: en-US X-Rspamd-Queue-Id: 4B3TZ24YZWz44vM X-Spamd-Bar: ++++++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yuripv.dev header.s=fm1 header.b=lZxCkh66; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=OLT/poFN; dmarc=none; spf=pass (mx1.freebsd.org: domain of yuripv@yuripv.dev designates 64.147.123.27 as permitted sender) smtp.mailfrom=yuripv@yuripv.dev X-Spamd-Result: default: False [6.53 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(0.00)[+ip4:64.147.123.27:c]; HAS_ATTACHMENT(0.00)[]; URIBL_RED(3.50)[yuripv.dev:dkim]; MIME_BASE64_TEXT_BOGUS(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[yuripv.dev:+,messagingengine.com:+]; MIME_BASE64_TEXT(0.10)[]; CTYPE_MIXED_BOGUS(1.00)[]; NEURAL_HAM_SHORT(-0.06)[-0.058]; HAS_ANON_DOMAIN(0.10)[]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:11403, ipnet:64.147.123.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.27:from]; ARC_NA(0.00)[]; R_DKIM_ALLOW(0.00)[yuripv.dev:s=fm1,messagingengine.com:s=fm3]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; DMARC_NA(0.00)[yuripv.dev]; NEURAL_SPAM_MEDIUM(0.66)[0.662]; BAD_REP_POLICIES(0.10)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.33)[0.331]; GREYLIST(0.00)[pass,body] X-Spam: Yes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 23:21:15 -0000 This is a multi-part message in MIME format. --------------B7B098E381178D7AA584F23E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Mark Millard wrote: > > > On 2020-Jul-10, at 11:05, Yuri Pankov wrote: > >> Steve Wills wrote: >>> On 11/28/19 4:08 PM, Mark Millard via svn-src-head wrote: >>>>> Author: daichi >>>>> Date: Fri Sep 20 17:37:23 2019 >>>>> New Revision: 352558 >>>>> URL: >>>>> https://svnweb.freebsd.org/changeset/base/352558 >>>>> >>>>> >>>>> Log: >>>>> top(1): support multibyte characters in command names (ARGV array) >>>>> depending on locale. >>>>> - add setlocale() >>>>> - remove printable() function >>>>> - add VIS_OCTAL and VIS_SAFE to the flag of strvisx() to display >>>>> non-printable characters that do not use C-style backslash sequences >>>>> in three digit octal sequence, or remove it >>>>> This change allows multibyte characters to be displayed according to >>>>> locale. If it is recognized as a non-display character according to the >>>>> locale, it is displayed in three digit octal sequence. >>>>> >>>> >>>> Initially picking on tab characters as an example of what is >>>> probably a somewhat broader issue . . . >>>> >>>> Ever since this change, characters like tabs that do not fit >>>> in the next character cell when output, but for which they >>>> are !isprintable(...), now mess up the top display. Again >>>> using tab as an example: line wrapping from the text having >>>> been shifted over by more than one character cell. top does >>>> not track the line wrapping result in how it decides what >>>> to output for the following display updates. >>>> >>> Apologies for the way late reply here, but I just now bothered tracking this down. This commit seems to be the cause of some corruption I'm seeing in long running top(1) as well. As Mark mentions, if I use "hh" it clears up. Should I open a bugzilla bug? I can share screenshots of the corruption, such as: >>> https://i.imgur.com/Xqlwf9h.png >>> https://i.imgur.com/Jv0d5NU.png >> >> Does removing VIS_SAFE fixes the issue for you? >> >> As for original Mark's report (which I missed), removing isprintable() doesn't look wrong as vis(3) should take of its functionality (and in multibyte-aware way). > > vis (as used) and the old isprintable logic are not > equivalent when multi-byte is not needed/involved. > Otherwise I'd not have had anything to ever report. > If vis can do what is needed, more work needed to > be done when the change was made in order to avoid > msesed up displays in single-byte contexts. > >> Also, is there an easy way to reproduce this? > > The following sort of command (the empty space inside quoted > text are tab characters): > > # tr '0\n 1\n 2\n 3\n 4\n 5\n 6\n 7\n 8\n' '\t0 \t1 \t2 \t3 \t4 \t5 \t6 \t7 \t8' < /dev/zero > /dev/null > > causes my 200 character wide window running top to show: > > 32920 root 100 0 12764Ki 2420Ki CPU3 3 2:22 99.87% tr 0\\n 1\\n 2\\n 3\\n 4\\n 5\\n 6\\n 7\\n 8\\n \\t0 \\t1 \\t2 \\t3 \\t4 \\t5 \\t6 \\t733 \\t8 20 7172 5448Ki CPU23 23 0:00 0.04% top -HiSCazopid > > But that does not show where the lines wrap at the edges of the window, > so breaking it up explicitly after the first "\" in \\7: > > 32920 root 100 0 12764Ki 2420Ki CPU3 3 2:22 99.87% tr 0\\n 1\\n 2\\n 3\\n 4\\n 5\\n 6\\n 7\\n 8\\n \\t0 \\t1 \\t2 \\t3 \\t4 \\t5 \\t6 \ > \t733 \\t8 20 7172 5448Ki CPU23 23 0:00 0.04% top -HiSCazopid > > Note how \n turned into \\n , taking an extra character for > each \n . Similarly for \t vs. \\t . (Other examples do > similarly.) > > The tab characters really do use more than one character cell > on the display (sometimes). > > The text from the tr command ends up spread across 2 lines > as things look like in the window where top is running. > > I ran top in another ssh session first and then the tr command. > Before running the tr command, top showed as: > > 33019 root 20 0 17172Ki 5448Ki CPU24 24 0:00 0.05% top -HiSCazopid > > If you do not end up with top listed just after tr in top's output, > then it will not be top's line that ends up partially overwritten. > > If you have wider windows, you may need more text in the tr quoted > strings. > > In another experiment I inserted a large number of backspace characters > (control-H's) at the front of the first quoted string in the tr command. > The top output displayed: > > 0\\n5 ro1\\n 2\\93 3\\n12764\\n 25\\ni CP6\\n 97\\n:12 100.00\t0r \nHiS\\t1pid \\t2 \\t3 \\t4 \\t5 \\t6 \\t > 33094 root 20 0 17172Ki 5488Ki CPU21 21 0:00 0.06% top -HiSCazopid > > In other words, backspace moved the cursor position back over prior > fields on the line and then the later line content overwrote those > fields instead of being after "tr" someplace (or truncated off). > > Note that part of "-HiSCazopid" shows up on both lines. The extra > is from when top was running but tr had not started yet. top is > not managing text replacement correctly for output characters that > end up not being just "in" the next character-cell on the terminal. > > The same sort of result happens when instead adding just one > carriage return (control-M) in front of that first quuoted > string instead: > > 0\\n8 ro1\\n 2\\92 3\\n12764\\n 25\\ni CP6\\n 117\\n:11 100.00\t0r \nHiS\\t1pid \\t2 \\t3 \\t4 \\t5 \\t6 \\t > 33094 root 20 0 17172Ki 5488Ki CPU23 23 0:00 0.04% top -HiSCazopid > > I do not intend to try to find all examples of characters that > cause problems but used to not cause problems. > > From what I've seen, cursor positioning escape character sequences > seem to be sent through and cause overwrites at arbitrary places > on screen, based on the escape sequence content. There are command > lines around that contain such sequences. So I sometimes see the > first few lines of top's output have garbage text from commands > that were listed below at some point overwriting the top text. > > Part of what is going on is top avoiding rewriting characters > that its tracking indicates have not been updated. When the > actual display and that supposed-tracking mismatch, the > display ends up wrong when updated (bad text continues to > display). > > The text in commands should not make "top -a" output mess up > the display of other lines in top's output, nor of other > top output fields on the same line. In my view, if some usage > contexts need otherwise, it should take an extra command line > option to put top in a mode that might do such things. The > default behavior should strictly avoid having such things > happen. Thanks. The attached diff seems to take care of the issue for me, adding VIS_TAB and removing VIS_SAFE, which can be blamed for passing through the following: VIS_SAFE Currently this form allows space, tab, newline, backspace, bell, and return — in addition to all graphic characters — unencoded. --------------B7B098E381178D7AA584F23E Content-Type: text/plain; charset=UTF-8; name="top.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="top.txt" SW5kZXg6IG1hY2hpbmUuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBtYWNoaW5lLmMJKHJldmlzaW9u IDM2MzAzNSkKKysrIG1hY2hpbmUuYwkod29ya2luZyBjb3B5KQpAQCAtMTAxNiw3ICsxMDE2 LDcgQEAKIAkJCQlsZW4gPSAoYXJnYnVmbGVuIC0gKGRzdCAtIGFyZ2J1ZikgLSAxKSAvIDQ7 CiAJCQkJc3RydmlzeChkc3QsIHNyYywKIAkJCQkgICAgTUlOKHN0cmxlbihzcmMpLCBsZW4p LAotCQkJCSAgICBWSVNfTkwgfCBWSVNfQ1NUWUxFIHwgVklTX09DVEFMIHwgVklTX1NBRkUp OworCQkJCSAgICBWSVNfTkwgfCBWSVNfVEFCIHwgVklTX0NTVFlMRSB8IFZJU19PQ1RBTCk7 CiAJCQkJd2hpbGUgKCpkc3QgIT0gJ1wwJykKIAkJCQkJZHN0Kys7CiAJCQkJaWYgKChhcmdi dWZsZW4gLSAoZHN0IC0gYXJnYnVmKSAtIDEpIC8gNCA+IDApCg== --------------B7B098E381178D7AA584F23E--