reproducible in any 12.0-RELEASE. (11.2-RELEASE and older do not seem to have the issue) - run xterm or tmux, resize it to 75 or 76 or 77 columns (tried a few other sizes, seems to segfault only with these three) - run top, let it update 1-2 times - resize terminal wide (resizing narrow won't cause the segfault). for completeness here is the backtrace (not too useful without debug symbols, but still) # lldb -c top.core /usr/bin/top (lldb) target create "/usr/bin/top" --core "top.core" Core file '/root/top.core' (x86_64) was loaded. (lldb) bt * thread #1, name = 'top', stop reason = signal SIGSEGV * frame #0: 0x00000008004d87dd libc.so.7`memcpy + 205 frame #1: 0x00000008004d65cd libc.so.7`___lldb_unnamed_symbol1635$$libc.so.7 + 397 frame #2: 0x0000000800470a0c libc.so.7`___lldb_unnamed_symbol1024$$libc.so.7 + 14044 frame #3: 0x00000008003ddd0f libc.so.7`vsnprintf + 287 frame #4: 0x000000080031d81a libsbuf.so.6`sbuf_vprintf + 138 frame #5: 0x000000080031db0d libsbuf.so.6`sbuf_printf + 141 frame #6: 0x000000000020af47 top`___lldb_unnamed_symbol54$$top + 1319 frame #7: 0x000000000020e428 top`___lldb_unnamed_symbol77$$top + 2296 frame #8: 0x000000000020611b top`___lldb_unnamed_symbol1$$top + 283 (lldb)
FWIW, I'm not able to reproduce this on -CURRENT.
I can confirm this bug on FBSD 12-RELEASE. pprocacci@yoda:~ % lldb -c top.core /usr/lib/debug/usr/bin/top.debug (lldb) target create "/usr/lib/debug/usr/bin/top.debug" --core "top.core" Core file '/home/pprocacci/top.core' (x86_64) was loaded. (lldb) bt * thread #1, name = 'top', stop reason = signal SIGSEGV * frame #0: 0x00000000002085dd top.debug`u_process(line=0, newline=0x0000000000000000) at display.c:856 frame #1: 0x000000000020e431 top.debug`main(argc=2147483647, argv=0x00000008007af000) at top.c:652 frame #2: 0x000000000020611b top.debug`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1.c:76 display.c:856 is the following: newline[screen_width] = '\0';
(In reply to pprocacci from comment #2) Following up with myself with a fix that maybe you'd like to employ: # svnlite co https://svn.freebsd.org/base/head/usr.bin/top /usr/src/usr.bin/top.new # cd /usr/src/usr.bin/top.new # make # make install There has been memory allocation related work that does indeed fix this bug that's currently in current. The above, will take that `top` from current and install it, fixing the bug you are encountering on 12-RELEASE.
(In reply to pprocacci from comment #3) Can you verify that the problem is fixed on stable/12? That is, if you fetch usr.bin/top from stable/12 instead of head, are you able to reproduce the crash?
# svnlite co https://svn.freebsd.org/base/stable/12/usr.bin/top /usr/src/usr.bin/top.stable12 # cd /usr/src/usr.bin/top.stable12 # make # make install With the above, I can confirm that the bug _IS NOT_ present in stable 12.
(In reply to pprocacci from comment #5) Thanks for confirming. In that case I will resolve the bug as fixed in stable/12; the issue will be gone in 12.1.