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):
Steps to Reproduce:
1. Start xterm
2. Run screen
3. Generate a beep flash by backspacing a few times.
The screen should flash (reverse video) then continue.
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
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.
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.
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:
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.
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'
# gzip core.*
Please append the core.*.gz file to this bug report - thanks.
Created attachment 126842 [details]
xterm core dump on visual bell in screen
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)
3. Core dump uploaded.
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:
Sorry, that URL should have been:
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.
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!
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.
Created attachment 126864 [details]
screen strace output where it just quits
The output from the command: strace -vfo /tmp/screen.strace.out screen
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 ?
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
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.
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.
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:
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.
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.
Created attachment 127005 [details]
Patch against xterm-211 which fixes the problem
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
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.
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.