Bug 186935 - xterm Segmentation Fault when screen flases the screen
Summary: xterm Segmentation Fault when screen flases the screen
Alias: None
Product: Fedora
Classification: Fedora
Component: xterm
Version: 5
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Miroslav Lichvar
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-03-27 15:54 UTC by Gregory Gulik
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version: xterm-211-1.FC5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-08-17 15:36:49 UTC
Type: ---

Attachments (Terms of Use)
xterm core dump on visual bell in screen (2.79 MB, application/octet-stream)
2006-03-27 18:39 UTC, Gregory Gulik
no flags Details
screen strace output where it just quits (102.10 KB, text/plain)
2006-03-27 23:31 UTC, Gregory Gulik
no flags Details
Patch against xterm-211 which fixes the problem (1.01 KB, patch)
2006-03-29 17:03 UTC, Jason Vas Dias
no flags Details | Diff

Description Gregory Gulik 2006-03-27 15:54:53 UTC
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):


How reproducible:


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 16:07:17 UTC
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 17:56:31 UTC
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 18:02:04 UTC
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:
[3]+  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:

Comment 4 Gregory Gulik 2006-03-27 18:04:16 UTC
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 18:32:30 UTC
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.

Comment 6 Gregory Gulik 2006-03-27 18:39:36 UTC
Created attachment 126842 [details]
xterm core dump on visual bell in screen

Comment 7 Gregory Gulik 2006-03-27 18:41:41 UTC
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.

Comment 8 Jason Vas Dias 2006-03-27 20:05:32 UTC
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:


Comment 9 Jason Vas Dias 2006-03-27 20:06:15 UTC
Sorry, that URL should have been:


Comment 10 Gregory Gulik 2006-03-27 20:09:25 UTC
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 22:24:26 UTC
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 - jvdias - thanks!

Comment 12 Gregory Gulik 2006-03-27 23:30:06 UTC
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 23:31:24 UTC
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-28 00:15:30 UTC
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-28 04:36:19 UTC
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.

Comment 16 Jason Vas Dias 2006-03-28 16:02:38 UTC
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 19:58:28 UTC
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.

Comment 18 Jason Vas Dias 2006-03-29 17:01:19 UTC
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 17:03:00 UTC
Created attachment 127005 [details]
Patch against xterm-211 which fixes the problem

Comment 20 Thomas E. Dickey 2006-03-29 17:10:23 UTC
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 18:41:47 UTC
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 18:51:25 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.