retitle 282708 xserver-xfree86: [ati/radeon] SEGV related to xscreensaver, full-screen SDL apps, KDE, and attempted keyboard grabs while X VT inactive on Radeon R200 BB [Radeon All in Wonder 8500DV] rev 0
tag 282708 + upstream moreinfo
thanks
On Tue, Nov 23, 2004 at 10:49:57PM +0100, Yann Dirson wrote:
> Package: xserver-xfree86
> Version: 4.3.0.dfsg.1-8
> Severity: important
>
> The crash is 100% reproducible on my box, but I feel the context is still a
> bit too wide, given the large software to reproduce.
I'm sorry it has taken a while to get back to you about this.
> How to get it:
>
> - run an X server with KDE (fvwm won't do), either from gdm or from startx
> with a simple "startkde" in the .xsession
>
> - run xscreensaver in the background
>
> - arrange to have xscreensaver activated while an SDL app (eg. wesnoth or
> pachi) is running full-screen (the same apps in windowed mode won't do), and
> you have switched to another console (either X or text). I usually do that
> by running the app in windowed mode, running "sleep 10; xscreensaver-command
> -lock" in an xterm, and switching the app to fullscreen, then to another VT
> during the sleep time.
>
>
> If I do not switch VT, I see xscreensaver complaining that it cannot grab
> the keyboard (I presume this is where the full-screen SDL part thing comes
> into action), but X still survives.
>
> If I switch to the text console from which I launched startx, I can see the
> "SetGrabKeysState - disabled" message appearing quite shortly before the
> crash.
>
> I cannot see how KDE interacts with all this. I could even reproduce from a
> freshly-created user account, running kde rom startx, and skipping the
> configuration wizard, to make sure there is no special config item involved.
Can anyone else reproduce this?
(In the future, please include your XF86Config-4 in bug reports against
xserver-xfree86{,-dbg}.)
[The following is a form letter.]
Can you reproduce the problem with xserver-xfree86-dbg? Install the
package and tell debconf you want to use that X server. Then restart the X
server and try to reproduce the bug (hopefully, this is easy). If it
doesn't crash, let us know. If a bug is in the XFree86 X server's ELF
module loader, you likely won't see it when you use the debugging server.
We still want to know that information. If it does crash, become root,
enable core dumps ("ulimit -c unlimited" in bash), start the X server as
root and reproduce the crash again:
# startx $(which x-terminal-emulator) -- :1
(If no X server is running at DISPLAY=:0, you can leave off the "-- :1"
part).
This will launch the X server running a lone terminal client with no window
manager. Run the client that provokes the crash from the terminal prompt.
If you can only reproduce the crash with a more elaborate environment, then
go ahead and produce that environment. Be sure to tell us what you did to
get it (e.g., launching GNOME or KDE, setting up a particular screensaver,
running an SDL game -- whatever it takes). It is not wise to run X clients
as root except when absolutely necessary, so if the session doesn't crash,
don't leave it running. Shut it down as soon as you can. It might also be
a good idea to scrub out root's home directory (/root) of hidden files and
directories created by desktop environments and whatever X clients you
attempted to reproduce the crash with. Look for /root/.gnome /root/.kde,
and so forth.
If the X server crashes, it should leave a core dump in /etc/X11.
We then run the GNU Debugger, GDB, on the core file and executable. We're
interested in a backtrace of execution. The X server has a signal handler
in it so it can do things like exit gracefully (restoring the text console,
and so forth), so we're not actually interested in all the stack frames --
just those "above" the signal handler.
Here's an example GDB session I logged after provoking an artificial server
crash (with "kill -SEGV").
% gdb $(which XFree86-debug) core
GNU gdb 6.1-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-linux"...Using host libthread_db library "/lib/libthread_db.so.1".
Core was generated by `/usr/X11R6/bin/X :1'.
Program terminated with signal 6, Aborted.
Reading symbols from /usr/lib/libfreetype.so.6...done.
Loaded symbols for /usr/lib/libfreetype.so.6
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0 0x400f2721 in kill () from /lib/libc.so.6
(gdb) bt
#0 0x400f2721 in kill () from /lib/libc.so.6
#1 0x400f24c5 in raise () from /lib/libc.so.6
#2 0x400f39e8 in abort () from /lib/libc.so.6
#3 0x08464b8c in ddxGiveUp () at xf86Init.c:1173
#4 0x08464c6b in AbortDDX () at xf86Init.c:1224
#5 0x08508bd7 in AbortServer () at utils.c:436
#6 0x0850a563 in FatalError (f=0x8a26ea0 "Caught signal %d. Server aborting\n") at utils.c:1421
#7 0x0847fbf5 in xf86SigHandler (signo=11) at xf86Events.c:1198
#8 <signal handler called>
#9 0x40199dd2 in select () from /lib/libc.so.6
#10 0x401f8550 in ?? () from /lib/libc.so.6
#11 0x400164a0 in ?? () from /lib/ld-linux.so.2
#12 0xbffff8f0 in ?? ()
#13 0x08502520 in WaitForSomething (pClientsReady=0xbffff944) at WaitFor.c:350
#14 0x084cff54 in Dispatch () at dispatch.c:379
#15 0x084e763c in main (argc=2, argv=0xbffffe04, envp=0xbffffe10) at main.c:469
(gdb) bt full -7
#9 0x40199dd2 in select () from /lib/libc.so.6
No symbol table info available.
#10 0x401f8550 in ?? () from /lib/libc.so.6
No symbol table info available.
#11 0x400164a0 in ?? () from /lib/ld-linux.so.2
No symbol table info available.
#12 0xbffff8f0 in ?? ()
No symbol table info available.
#13 0x08502520 in WaitForSomething (pClientsReady=0xbffff944) at WaitFor.c:350
i = 2
waittime = {tv_sec = 118, tv_usec = 580000}
wt = (struct timeval *) 0xbffff910
timeout = 599999
standbyTimeout = 1199999
suspendTimeout = 1799999
offTimeout = 2399999
clientsReadable = {fds_bits = {0 <repeats 32 times>}}
clientsWritable = {fds_bits = {1, 146318192, -1073743800, 140704020, 147350456, 147350040, 2, 312, 1, 1075418973, -1073743800, 139461033, 147374816, 1, -1073743680, 9, 1073833120, -1073742332,
-1073743784, 139526463, 9, -1073743680, 1, 139458611, 147350456, 147350040, -1073743752, 139529154, 147339744, -1073743680, 1, 1074655182}}
curclient = 147556952
selecterr = 3
nready = 0
devicesReadable = {fds_bits = {1, 1, 6, 146327832, 147350508, 0, 315, 302, 9, 3, 315, 302, 9, 3, 0, 0, 146318192, 1075807568, -1073743880, 137843170, 146125816, 3, 313, 147556952, 0, 15066597, 3,
-1, 147350500, 1, 0, 146319268}}
now = 16069
someReady = 0
#14 0x084cff54 in Dispatch () at dispatch.c:379
clientReady = (int *) 0xbffff944
result = 0
client = 0x8c8c2e0
nready = -1
icheck = (HWEventQueuePtr *) 0x8b45c68
start_tick = 940
#15 0x084e763c in main (argc=2, argv=0xbffffe04, envp=0xbffffe10) at main.c:469
i = 1
j = 2
k = 2
error = -1073742332
xauthfile = 0xbfffffba "/root/.Xauthority"
alwaysCheckForInput = {0, 1}
(gdb) quit
In the example above, you can see I used "bt full -7" to get the
"outermost" seven stack frames, complete with local variable information,
where available. Your stack trace may vary. We want to see all the stack
frames *below* (numbered greater than) "<signal handler called>" in the
list. If you get confused, just send us the output of "bt full" (with no
number after it) and we'll sort it out.
If you could send us such a stack trace, that would be very helpful.
--
G. Branden Robinson | The key to being a Southern
Debian GNU/Linux | Baptist: It ain't a sin if you
branden@debian.org | don't get caught.
http://people.debian.org/~branden/ | -- Anthony Davidson
Attachment:
signature.asc
Description: Digital signature