Bug 186935

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:
[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)

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'
     SIGSEGV 
   )
   # 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)

2. GNOME

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:
  http://people.redhat.com/xterm/xterm-211-2.FC5.i386.rpm

Thanks!
                                 

Sorry, that URL should have been:

http://people.redhat.com/~jvdias/xterm/xterm-211-2.FC5.i386.rpm

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 - jvdias - 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
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.

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:
  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.

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
"unrelated" one.

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.