Red Hat Bugzilla – Full Text Bug Listing
|Summary:||xterm Segmentation Fault when screen flases the screen|
|Product:||[Fedora] Fedora||Reporter:||Gregory Gulik <greg>|
|Component:||xterm||Assignee:||Miroslav Lichvar <mlichvar>|
|Status:||CLOSED ERRATA||QA Contact:|
|Fixed In Version:||xterm-211-1.FC5||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-08-17 11:36:49 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Gregory Gulik 2006-03-27 10:54:53 EST
Description of problem: I regularly run xterms with screen inside them. After upgrading to FC5 I found that xterms were Segmentation Fauling on a regular basis. After some testing I tracked it down to running screen within the xterms. I have screen set up to flash the screen for a beep. I can now get xterm to crash 100% of the time by causing the screen to be flashed by screen. Version-Release number of selected component (if applicable): xterm-209-4 How reproducible: Always Steps to Reproduce: 1. Start xterm 2. Run screen 3. Generate a beep flash by backspacing a few times. Actual results: Segmentation Fault Expected results: The screen should flash (reverse video) then continue. Additional info: I have been unable to get xterm to produce a core dump. I even tried running xterm as root but for some reason screen refuses to run in a root xterm and just gives me this error: [root@penguin ~]# screen /var/run/screen/S-root/4531.pts-2.penguin: No such file or directory
Comment 1 Jason Vas Dias 2006-03-27 11:07:17 EST
Sorry to hear xterm-209-4 is crashing with screen - I'll investigate. Meanwhile, perhaps you could try xterm-211-1.FC5, available since last week in FC5/Updates/Testing, and just now being pushed to Updates/Final. You should be able to get xterm to generate a coredump on a SIGSEGV as follows: # ulimit -c unlimited ; # xterm ... Then if xterm gets a SIGSEGV it will create a core.$pid file in the cwd. If you can still reproduce the problem with 211, please generate a coredump as above, compress it and append it to this bug - thanks.
Comment 2 Jason Vas Dias 2006-03-27 12:56:31 EST
I cannot reproduce this problem with the current xterm-211-1.FC5 in FC-5/6, or with xterm-208-4 in FC4 (I had 'vbell on' in ~/.screenrc, and did: $ echo -e '\007' repeatedly in xterm - no crash occurred.) If you can reproduce this with xterm-211.FC5, please re-open this bug and append the compressed core dump file and your ~/.screenrc to this bug report - thanks.
Comment 3 Gregory Gulik 2006-03-27 13:02:04 EST
I don't have a .screenrc so all my settings are defaults. If I start up xterm, then start screen then enter $ echo -e '\007' The xterm immediately disappears with a: + Segmentation fault xterm in the screen where I started the xterm I noticed the xterm was updated this morning so I immediately upgraded. It's still crashing under the latest xterm: xterm-211-1.FC5 X.Org 184.108.40.2063(211)
Comment 4 Gregory Gulik 2006-03-27 13:04:16 EST
Ok, just tried a few things. Within the screen I hit CTRL-A CTRL-G to switch from audible to visual bell. With audible bell I don't get a crash but don't get a audible beep either. With visual bell the xterm crashes immediately.
Comment 5 Jason Vas Dias 2006-03-27 13:32:30 EST
I still cannot reproduce this on a clean-installed FC-5 i386-smp running KDE, without any ~/.screenrc file, as root or non-root user. Please supply some further information: 1. What architecture is the machine on which you have the problem ? ie. i386, x86_64, ia64, ppc ... 2. Which Window Manager are you running ? ie. KDE, GNOME, openmotif ... 3. You can gather a core dump file as follows: # ulimit -c unlimited # xterm -e screen ( then in xterm: # echo -e '\007' SIGSEGV ) # gzip core.* Please append the core.*.gz file to this bug report - thanks.
Comment 6 Gregory Gulik 2006-03-27 13:39:36 EST
Created attachment 126842 [details] xterm core dump on visual bell in screen
Comment 7 Gregory Gulik 2006-03-27 13:41:41 EST
I have only two FC5 systems currently, both are fresh installs and fully up to date. I am only able to duplicate this bug on of them, an AMD Athlon desktop. 1. Architecture is i386 (Athlon XP) 2. GNOME 3. Core dump uploaded.
Comment 8 Jason Vas Dias 2006-03-27 15:05:32 EST
Thanks for appending the core dump. I think I may have found and fixed a potential cause of the problem - but as I still cannot reproduce the problem, please could you download and test this RPM: http://people.redhat.com/xterm/xterm-211-2.FC5.i386.rpm Thanks!
Comment 9 Jason Vas Dias 2006-03-27 15:06:15 EST
Sorry, that URL should have been: http://people.redhat.com/~jvdias/xterm/xterm-211-2.FC5.i386.rpm
Comment 10 Gregory Gulik 2006-03-27 15:09:25 EST
I upgraded to that version of xterm but screen will not run inside. xterm -e screen quits immediately Running xterm then running screen at the command line just returns with no error immdiately and no screen is running.
Comment 11 Jason Vas Dias 2006-03-27 17:24:26 EST
Very strange - I'm able to run screen with no problems in both xterm versions. But xterm does not generate a core dump now, no ? Please try gathering an strace to determine why screen is exiting: 1. Run xterm 2. In xterm shell, type: # strace -vfo /tmp/screen.strace.out screen Then, when screen exits, please compress /tmp/screen.strace.out and append it to this bug report or send it to me - email@example.com - thanks!
Comment 12 Gregory Gulik 2006-03-27 18:30:06 EST
No, it doesn't core dump but I can't bring up screen to reproduce the core dump. Ok, I tried the strace and will attach the output to this report.
Comment 13 Gregory Gulik 2006-03-27 18:31:24 EST
Created attachment 126864 [details] screen strace output where it just quits The output from the command: strace -vfo /tmp/screen.strace.out screen
Comment 14 Jason Vas Dias 2006-03-27 19:15:30 EST
It could be that when screen terminated when xterm got a SIGSEGV, it left some server socket / lock files around that now prevent it starting up. Please try this - as root: # pkill screen # rm -rf /var/run/screen/* # chmod 0777 /var/run/screen Then try the 'xterm -e screen' command again as a non-root user. Does it still fail ?
Comment 15 Gregory Gulik 2006-03-27 23:36:19 EST
Ok, did everything you recommended. I kill off all instances of screen, removed everything from /var/run/screen, made it readable/writable by everyone then tried "xterm -e screen" and it immediately returned. I then tried running xterm and running screen from inside there. I got the following: Directory '/var/run/screen' must have mode 775. So I then fixed the permisions to 775 and re-ran screen. This time it ran fine inside xterm version xterm-211-2 but when I brought up screen and caused a visual bell it once again caused xterm to core dump.
Comment 16 Jason Vas Dias 2006-03-28 11:02:38 EST
OK, please can you send me the new core dump - $ ulimit -c unlimited $ rm -f core.* $ xterm -e screen ( do visual bell causing SIGSEGV ) $ gzip core.* and please send me the core.*.gz files - thanks.
Comment 17 Jason Vas Dias 2006-03-28 14:58:28 EST
Thanks for sending me the core dump file - I think I may have found and fixed the problem now. Please repeat the test with this RPM: http://people.redhat.com/~jvdias/xterm/xterm-211-2.1.dbg.i386.rpm I don't think this version should get a SIGSEGV anymore - if it does, please me send the core file. The xterm version from xterm-211-2.1.dbg.i386.rpm has tracing enabled, and will create the files 'Trace-parent.out' and 'Trace-child.out' in the current directory each time it is run - please can you send me the 'Trace-parent.out' file from an '-e screen' visual bell test run . It seems that the core occurs when free-ing X Extension data associated with the cursor GCs. When I run xterm on FC-5 with '-e screen', the cursor GCs never have any X extension data - so I don't see any SIGSEGVs. Have you intentionally enabled any X Extensions (eg. Xinerama) ? Please can you append your /etc/xorg.conf file to this bug report or send it to me - thanks.
Comment 18 Jason Vas Dias 2006-03-29 12:01:19 EST
OK, this problem is now fixed - thanks for testing the RPMs . releaseCursorGCs must use XtReleaseGC to free the cursor GCs, since they were obtained with XtGetGC . For some reason, on the one machine where the problem occurred, Xt was allocating shared GCs for the cursor GCs (reference count was 4) and was using the GC ext_data to hold pointers, even though there was no extension loaded that provided the create_gc callback. Anyway, simply replacing the calls to XFreeGC with calls to XtReleaseGC in charproc.c's releaseCursorGC fixes the problem.
Comment 19 Jason Vas Dias 2006-03-29 12:03:00 EST
Created attachment 127005 [details] Patch against xterm-211 which fixes the problem
Comment 20 Thomas E. Dickey 2006-03-29 12:10:23 EST
I seem to recall (will check when working on #212) that long ago I had changed the XtReleaseGC's to XFreeGC's because Xt would not really return a distinct GC when I asked for a new one, so some of the changes to "one" GC would modify an "unrelated" one.
Comment 21 Fedora Update System 2006-03-29 13:41:47 EST
xterm-211-4.FC5 has been pushed for FC5, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
Comment 22 Fedora Update System 2006-05-03 14:51:25 EDT
xterm-212-1.FC4 has been pushed for fc4, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.