Bug 186935 - xterm Segmentation Fault when screen flases the screen
xterm Segmentation Fault when screen flases the screen
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: xterm (Show other bugs)
5
All Linux
medium Severity high
: ---
: ---
Assigned To: Miroslav Lichvar
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-27 10:54 EST by Gregory Gulik
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: xterm-211-1.FC5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-17 11:36:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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

  None (edit)
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:
[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:
xterm-211-1.FC5
X.Org 6.8.99.903(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 - jvdias@redhat.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.

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