From owner-freebsd-current@freebsd.org Mon Dec 23 05:41:55 2019 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 8E7BA1E614F for ; Mon, 23 Dec 2019 05:41:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-20.consmr.mail.gq1.yahoo.com (sonic302-20.consmr.mail.gq1.yahoo.com [98.137.68.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47h7X22JfJz4GC8 for ; Mon, 23 Dec 2019 05:41:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 4YgRQwsVM1n5nX1hjP.X5FpEf6UgfhSJqA8TV2u5JklgRJWa9COLp94MUOnrZRM cf5L_o90vd5eXWeTMtsXpqrwf3GMOItsJUn09qAMJEMu8HdzkKS_2W2twal7LGYCLlkLIGzSaPha vgJ2prKoATdoEiTSgDPwo8hxApvISKTYguTHFArpISHUeU0MPUwWTxqrbuW8qSlII0Q7w7M9jbZ3 s30fYhruLCLngZpI9_S739duMCtdAAUg.p87e7HSBqPPKQh5.vtA2oixKk4.1wck.A_AavEUmfgC Xc3aueGqqYO4yNTR_TY5e3uK7O2HCYHQCNrAIgvAAFwFmXe2MuYRlDepOOrWk3oorunNuotBotJV q1kJI22WQAxOf7zzVybSYSyzyE1YHGDD9u9e1S.ILIkeA8cvUuAHmJZb8CcKK5fZnx2q4WenHO2j k72qecQMPG5PjPbHBvZayqTJRhosFDD1ZVxbE6Cdw8sbbmvnUDVG.89tZi.Q54QzEcxxijPeC4CP 8e07Ce43OhnrpsY9zIN4LjlgH4P_GkwPuuylY6ewe424WWFRMH9esx61AEyIS3QJ.AD5UU8AMkEa aL2NK0u6FDsdPcestXrXUo.x6Z1gEB1NmCCb6k6K6tS36DpzD142D.90Ths0a6E5HiRdxUyATB39 JqHQCdKSYNm4AAJJu5qh3ouAFE6ojjSK5L1zZWGXbKF3lzarsgOwXkrcoDAkclLiz5TQMgIAtC5n IRW_Wr5Y0ImOYRqAC.MIpHNUquMQiHz4m6gokNf_dXk3GVNOK.RYtHnCXznFdJFDa.vDIIz3HUQz MaWYUJuXH3yTvf7eeTIFAQVQSrxJl4flHmSTPgbQaELiVNOgQujp3NXYxprcUmrMhC8aOZtLTu2m lfoAqu40HupjriwezXWZNQzAcKmLjYLCxfyYkIdch7MK5rfi7n3kXO4p7KN8xtbXf3f3HDvqGIag q10zl79LVUgfVPGwl1mz5d2ZuwHgyjcy8KP7A1QHel54hWxNoZZbUZ2nWeMMkwa9kTFAiao8Go4N BL7rCkjbJVtZ4ikBGP5t64LVyxA9Gsp1ujHLEw4wCr1Mqt.sU0C4WFe1qngb0A8j0Wuh4U5QAUjG u4DgJWrrvQBNyGPWCW.G59N7MH75lIHfF9kzFSqO7Yt.x2AqgygIANL6uPF0LHFLQy2cIcXXE1fM W3j9OiiHO2ry7Qsoh2S_3hPxDrh11bPO_KaGZP9eMb7lO1bC3TSKFYbl8ZfKA.bP6Q0OVQz8b1Cw YFPhGESAZUmiVYq6EoBe0lxp2qc0.S.rXAy_0BZLjhZLO3NbBJJ82dwuK4WMDtMxv6am3bH5XkW9 1ZmA9Icd8K3MqwwfOZOo1N91_jh.uidYNNsN8PX3UH9EL3XItawnb7hclgfJRpR.3uznGLXbCnfw uqgnXfvtxxH9Sk9rPeClqUfRZDiI76b9vChk- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Mon, 23 Dec 2019 05:41:52 +0000 Received: by smtp428.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 29ea8fb6574188c630099388ae7d0485; Mon, 23 Dec 2019 05:41:49 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Long command lines messing up top's process list display: -r335850 related (in part)? Message-Id: Date: Sun, 22 Dec 2019 21:41:48 -0800 To: Eitan Adler , FreeBSD Current X-Mailer: Apple Mail (2.3608.40.2.2.4) References: X-Rspamd-Queue-Id: 47h7X22JfJz4GC8 X-Spamd-Bar: - X-Spamd-Result: default: False [-1.17 / 15.00]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.72)[-0.716,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.95)[-0.953,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (0.51), ipnet: 98.137.64.0/21(0.89), asn: 36647(0.71), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[146.68.137.98.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[146.68.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 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: Mon, 23 Dec 2019 05:41:55 -0000 I've been looking into why I see top sometimes overwriting text across multiple lines when watching buildworld activity (for example). An example (from a 200 column, 70 lines display window) is: 21041 root 74 0 11M 2380K CPU27 27 0:01 41.60% sed = \nbj/amd6/ [TDW] / {\n.amd64/usr/s/:.* [TDW] / /\nmp/usr/bin/c++ w = /tmp/_symbol_.uQMlIJnU\nn-freebsd13.0 d\nit-ob}\ndisab/ U / {\ n0981 root s/:52 U / /\n 20M 6156K pipewr 2 0:00 15.02% nm = -go Analysis/AliasAnalysis.o Analysis/AliasAnalysisEvaluator.o = Analysis/AliasAnalysisSummary.o Analysis/AliasSetTracker.o Analysi 21037 root 52 0 11M 2512K piperd 1 0:00 0.21% tsort = -q 21036 root 52 0 12M 3240K wait 22 0:00 0.32% = /bin/sh - = /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/legacy/usr/sbin/l= order Analysis/AliasAnalysis.o Analysis/AliasAna (The lorder/tsort/nm/sed sequence and its sed line might not be the only such context. But it seems to be a primary example for buildworld context.) The example is more readable than they are sometimes but I think makes clear the issue. You can see where top updates only parts of a line, not expecting other text to have changed --yet they have changed. (Also: The context is ssh-terminal sessions over ethernet, not error prone serial-line based terminal sessions.) I end up forcing top to rewrite its display from scratch to get rid of accumulated stray text. (hh, toggling the type of display and back.) Looking around I ran into: QUOTE Revision 335850 - (view) (download) (annotate) - [select for diffs]=20 Modified Sun Jul 1 19:44:29 2018 UTC (17 months, 3 weeks ago) by eadler=20= File length: 41331 byte(s)=20 Diff to previous 335836 top(1): permit infinite length for command There isn't any need to limit the size of the screen. Utilities like 'less -S' don't have a (meaningful) limit anyways. This also makes the way to dynamically changing the column widths based on the screen width. END QUOTE and it seems to have removed what originally stopped the sbuf for a line from outputting too much text for the space available on the line: it previously accounted for the prior columns already put to use vs. screen_width in use at the time and used the count of what space was left. (Some later revisions are related but all after -r335850 looked like they did not deal with limiting to the space available after the other columns at any stage that I found. In essence I'm trying to ask based on where it looks like the issue might have started.) Was some other part of the code supposed to prevent lines that can not fit the space from overwriting other text=20 from other processes in the list? It seems to be overwriting in a way that top does not track and does put back the other line's own text? (Of course, I may just not have found what was to deal with such, I'm not a top expert.) A related issue for the overall problem is . . . I also ran into the removal of printable mixed with the use of: strvisx(dst, src, MIN(strlen(src), len), VIS_NL | VIS_CSTYLE | VIS_OCTAL | = VIS_SAFE); When I looked up VIS_SAFE, I found: QUOTE VIS_SAFE Only encode "unsafe" characters. Unsafe means control = char- acters which may cause common terminals to perform = unexpected functions. Currently this form allows space, tab, = newline, backspace, bell, and return -- in addition to all = graphic characters -- unencoded. END QUOTE For tab, for example, sent "unencoded": Might this lead the cursor being out of the expected place for whatever text is to follow? (VIS_TAB is not used. The VIS_NL seems to override VIS_SAFE for newlines.) But it looks to me like backspace, bell, and return sent "unencoded" would not end up with the cursor where top expects it to end up for figuring out what to do next for updating the display, likely resulting in a messed up display as well. This change is more recent than -r335850. I may not have found all contributing changes for the display not updating correctly. But those two are what I've noticed looking around as possible contributors. I will note that my context is not a good test for UTF-8 handling and the like, except as the case of looks like ASCII with: # locale LANG=3D LC_CTYPE=3D"C" LC_COLLATE=3D"C" LC_TIME=3D"C" LC_NUMERIC=3D"C" LC_MONETARY=3D"C" LC_MESSAGES=3D"C" LC_ALL=3D So the coverage by my activity is limited, and on the simpler side. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)