Bug 34731 - startx followed by ctrl-alt-backspace sometime causes X to segfault
Summary: startx followed by ctrl-alt-backspace sometime causes X to segfault
Status: RESOLVED INVALID
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: unspecified
Hardware: Other Linux (All)
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-25 12:00 UTC by Charlotte Richardson
Modified: 2018-06-12 18:44 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Xorg.0.log file (showing component versions) (10.21 KB, application/octet-stream)
2011-02-25 12:00 UTC, Charlotte Richardson
no flags Details

Description Charlotte Richardson 2011-02-25 12:00:44 UTC
Created attachment 43829 [details]
Xorg.0.log file (showing component versions)

Some of our customers and partners run their server systems without
starting X at boot.  They log into a text mode console and run the
"startx" script.  They later type ctrl-alt-backspace to exit from X.
Sometimes, due to a race condition in how X handles the interrupt,
X segfaults instead of completely exiting and does not finish the
console handshake with the kernel.  That leaves the VT set at 7 and
the console with garbage pixels smeared across the screen.  No text
console is displayed and the user must connect to the system via
another device to recover use of the console.

On Red Hat RHEL 5.5, the easiest way to reproduce this is to open a
terminal window after X comes up and edit a file in that window using
"vi", then kill X via ctrl-atl-backspace.  Most of the time it works
but once in a while you lose the race and X segfaults.
I have not seen this happen on RHEL6 where a newer version of X is
shipped.

We use framebuffer drivers that may perturb the timing of the console
handshake.  I've attached the Xorg.0.log so you can see what versions
of the components are loaded.

Here is the stack trace (always the same) from the core file from X
when this problem happens:

(gdb) bt
#0  xorg_backtrace (signo=11) at xf86Events.c:1294
#1  xf86SigHandler (signo=11) at xf86Events.c:1482
#2  <signal handler called>
#3  0x000000393d272449 in _int_free () from /lib64/libc.so.6
#4  0x000000393d27276b in free () from /lib64/libc.so.6
#5  0x000000000050b49c in FreePicture (value=<value optimized out>, pid=1)
    at picture.c:1659
#6  0x00000000004d3414 in miDCCloseScreen (index=0, pScreen=0x140a93d0)
    at midispcur.c:188
#7  0x00000000004f104f in CursorCloseScreen (index=0, pScreen=0x140a93d0)
    at cursor.c:173
#8  0x0000000000514eae in AnimCurCloseScreen (index=1028991456, pScreen=0x1)
    at animcur.c:130
#9  0x00000000004337de in main (argc=5, argv=0x7fff8c3194f8,
    envp=<value optimized out>) at main.c:472

When X blows up like this, it is a zombie task for a while, but the process
eventually goes away, so it is not a permanent memory leak. If it did leak
memory that would be a major problem for our customers since our servers very
seldom get rebooted.

We have seen nothing in documentation from Red Hat or X.org to suggest that
using startx / ctrl-atl-backspace is an incorrect practice.  Users who are
in this habit rejected the X "ServerFlags" option "DontZap" because it
turns off a convenience feature.

Therefore, Stratus Technologies is seeking a fix, preferably one that
addresses the race condition within X.
Comment 1 Adam Jackson 2018-06-12 18:44:04 UTC
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.