screen 4.7.0_1 dumps core when used with TERM=rxvt-unicode-256color or TERM=rxvt.
Seen on freshly upgraded 11.3-STABLE box:
FreeBSD xxx 11.3-RELEASE-p3 FreeBSD 11.3-RELEASE-p3 #0: Mon Aug 19 21:08:43 UTC 2019 firstname.lastname@example.org:/usr/obj/usr/src/sys/GENERIC amd64 amd64 amd64 FreeBSD
as well as an non-upgraded 12.0-STABLE box:
FreeBSD xxx 12.0-STABLE FreeBSD 12.0-STABLE r345375 GENERIC amd64 amd64 amd64 FreeBSD
Starting program: /usr/local/bin/screen
[Attaching after LWP 100616 of process 54574 fork to child LWP 100786 of process 54578]
[New inferior 2 (process 54578)]
[Detaching after fork from parent process 54574]
[Inferior 1 (process 54574) detached]
Thread 2.1 received signal SIGSEGV, Segmentation fault.
[Switching to LWP 100786 of process 54578]
strlen (str=0x0) at /usr/src/lib/libc/string/strlen.c:100
warning: Source file is more recent than executable.
100 va = (*lp - mask01);
#0 strlen (str=0x0) at /usr/src/lib/libc/string/strlen.c:100
#1 0x00000000004225a5 in SaveStr (str=0x0) at misc.c:59
#2 0x0000000000439535 in InitTermcap (wi=0, he=0) at termcap.c:230
#3 0x0000000000406832 in main (ac=0, av=0x7fffffffea80) at screen.c:1370
Happens with screen setuid or non-setuid root (therefore unrelated to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241530)
Created attachment 208652 [details]
Quick fix : revert fad4c29fd95d30639a67142066f623396fca8536
A quick fix:
Reverting this change to screen 4.x branch:
Author: Amadeusz Sławiński <email@example.com>
Date: Sat Sep 7 17:58:50 2019 +0200
Fix broken mouse after ncurses 6.1
ncurses 6.1 changed kmous capability from "\e[M" to "\e[<". It seems to
be done to signal that terminal supports sgr mouse mode. screen assumed
that if kmous is set to "\e[M" it is on xterm compatible terminal
anyway, so just dynamically detect which one is used and override
InitKeytab() is moved, so kmapdef can be overriden before
initialization, as InitTermcap() needs to run first, as far as I can
tell this should have no consequences.
Signed-off-by: Amadeusz Sławiński <firstname.lastname@example.org>
Created attachment 208653 [details]
fix coredump on xterm and rxvt and bump portrevision
Here's the rub: with TERM=xterm (or rxvt, for that matter), Km ("key_mouse", "Mouse event has occured") is not set (and therefore NULL), but InitTermcap() (termcap.c:230) happily tries to strdup() that, which gets us that segfault.
As a band-aid, catch that NULL and don't strdup().
Workaround: set TERM to a terminal with Km - for example, TERM="xterm-v220" works just fine.
Thanks, you patch is better :)
I think it didn't crash for me with TERM=xterm though.
tput says it is there:
> tput -T xterm Km | hd
00000000 1b 5b 4d |.[M|
> tput -T rxvt Km || echo not found
(In reply to Marcin Cieślak from comment #4)
D'oh. Now that you mention that - I've set termName to "xterm-color" for my xterms (it has been years since I last touched my .Xresources...), and it's that xterm-color which has no Km (but it leaves TERM at "xterm", which confused me quite a bit). Yeah, real "xterm" is fine, but "xterm-color" (which disguises as xterm) is a problem.
Upstream report: https://lists.gnu.org/archive/html/screen-users/2019-10/msg00003.html
Since screen is again in active development, maybe we should upstream some of our local patches there?
(In reply to Christoph Moench-Tegeder from comment #2)
I'm at $JOB at the moment. Can you commit this for me please? Consider this my approval.
A commit references this bug:
Date: Mon Oct 28 14:42:21 UTC 2019
New revision: 515868
sysutils/screen: fix coredump on xterm/rxvt variants without Km
On xterm- and rxvt-variants (and in some other cases) screen's
InitTermcap() tries to strdup() the terminals "Km" ("key_mouse")
termcap attribute - but that might be NULL, as some of these
terminals (notably rxvt and xterm-color) do not have "Km". Trying
to strdup() NULL results in segfault and coredump.
Catch that NULL and prevent the segfault.
Reported by: Marcin Cie?lak, Gareth de Vaux
Approved by: cy@
committed as ports r515868 - thanks.
2 hours to fix - yay \o/
big thanks everyone!
I have submitted the patch upstream:
I hope this is ok for you Christoph!
(In reply to Marcin Cieślak from comment #11)
screen is GPLed, so yeah, it's fine (and really, rather trivial, once you see it).