On Sun, Dec 12, 2004 at 11:11:44PM +0100, David A. van Leeuwen wrote:
> OK, I got it. After another upgrade to `testing' today, and a reboot
> for a kernel parameter earlier today, My SiS6326 card started to crash
> more consistently, even with the dfsg.1-4 package. So I tried the
> -dbg_4.3.0.dfsg.1-8 package under root and unlimited core size, and
> after a while trying I caught the crash.
>
> I hope Mozilla (in which I can't seem to include text from a file---i
> must attach---sorry) shows the bug report properly.
>
> I've noticed that a typical behaviour is: server either crashes on one
> of the first 10-or-so launches of clients (doesn't matter which), or it
> doesn't, and then tends to live very long.
>
> I hope this information help you.
Hmm, well, given your backtrace, I might have been wrong about this being
SiS-specific.
See below.
> (gdb) bt
> #0 0x400f46b1 in kill () from /lib/libc.so.6
> #1 0x400f4435 in raise () from /lib/libc.so.6
> #2 0x400f5978 in abort () from /lib/libc.so.6
> #3 0x0847454c in ddxGiveUp () at xf86Init.c:1173
> #4 0x0847462b in AbortDDX () at xf86Init.c:1224
> #5 0x08516e5f in AbortServer () at utils.c:436
> #6 0x085187eb in FatalError (
> f=0x8a36fa0 "Caught signal %d. Server aborting\n") at utils.c:1421
> #7 0x0848f646 in xf86SigHandler (signo=11) at xf86Events.c:1230
> #8 <signal handler called>
> #9 0x40142a1f in memcpy () from /lib/libc.so.6
> #10 0x0892a025 in fs_read_list_info (fpe=0x8bcf350, blockrec=0x8d65198)
> at fserve.c:2376
> #11 0x089286fc in fs_read_reply (fpe=0x8bcf350, client=0x0) at fserve.c:1310
> #12 0x08928810 in fs_wakeup (fpe=0x8bcf350, mask=0x8b57f60) at fserve.c:1349
> #13 0x0850ae1d in FontWakeup (data=0x0, count=1, LastSelectMask=0x8b57f60)
> at dixfonts.c:190
> #14 0x084e759f in WakeupHandler (result=1, pReadmask=0x8b57f60)
> at dixutils.c:459
> #15 0x085107cb in WaitForSomething (pClientsReady=0xbffff8e4) at WaitFor.c:353
> #16 0x084de1dc in Dispatch () at dispatch.c:379
> #17 0x084f58c4 in main (argc=2, argv=0xbffffda4, envp=0xbffffdb0)
> at main.c:469
> (gdb) bt full -7
> #11 0x089286fc in fs_read_reply (fpe=0x8bcf350, client=0x0) at fserve.c:1310
> conn = 0x8bcf378
> blockrec = 0x8d65198
> ret = 1
> err = 85
> rep = (fsGenericReply *) 0x8bcf808
> #12 0x08928810 in fs_wakeup (fpe=0x8bcf350, mask=0x8b57f60) at fserve.c:1349
> LastSelectMask = (fd_set *) 0x8b57f60
> conn = 0x8bcf378
> #13 0x0850ae1d in FontWakeup (data=0x0, count=1, LastSelectMask=0x8b57f60)
> at dixfonts.c:190
> i = 0
> fpe = 0x8bcf350
> #14 0x084e759f in WakeupHandler (result=1, pReadmask=0x8b57f60)
> at dixutils.c:459
> i = 3
> j = 1074663374
> #15 0x085107cb in WaitForSomething (pClientsReady=0xbffff8e4) at WaitFor.c:353
> i = 1
> waittime = {tv_sec = 30, tv_usec = 0}
> wt = (struct timeval *) 0xbffff8b0
> timeout = 599800
> standbyTimeout = 1199800
> suspendTimeout = 1799800
> offTimeout = 2399800
> clientsReadable = {fds_bits = {0 <repeats 32 times>}}
> clientsWritable = {fds_bits = {1, 34572, -1073743944, 137854978,
> 148262064, 2048, -1073743912, 1, 146208600, 146208600, -1073743912,
> 137858932, 148262296, 81928, 0, 1075039169, 146208600, 857, 0,
> 1075818748, 0, 1075818728, 1075818732, -1073743888, 1075818656,
> 1075818656, -1073743816, 1075039169, 1075818656, 0, 1053956, 1075818656}}
> curclient = 16
> selecterr = 0
> nready = 1
> devicesReadable = {fds_bits = {16, 0, 0, 0, 16, 148264696,
> -1073744072, 139360755, 148264744, 148263348, 148263320, 146600824, 1,
> 148261712, -1073743752, 139511553, 148264744, 139510958, 148262504,
> -1073743792, -1073743892, -1073743796, 0, 148262232, 7, 56, 1075818656,
> 1075815968, 1075818656, 1075818656, -1073743976, 1075035747}}
> now = 43454
> someReady = 0
> #16 0x084de1dc in Dispatch () at dispatch.c:379
> clientReady = (int *) 0xbffff8e4
> result = 0
> client = 0x8d65728
> nready = -1
> icheck = (HWEventQueuePtr *) 0x8b55bc8
> start_tick = 4440
> #17 0x084f58c4 in main (argc=2, argv=0xbffffda4, envp=0xbffffdb0)
> at main.c:469
> i = 1
> j = 2
> k = 2
> error = -1073742428
> xauthfile = 0xbfffffb8 "/root/.Xauthority"
> alwaysCheckForInput = {0, 1}
> (gdb)
Can you show us the output of "bt full -9" instead, please? I'm sorry if
my instructions were confusing; the goal is to get a close look at the
stack frames *right below* the point where the signal handler is called.
That can tell us, for example, if what we're dealing with is a good
old-fashioned null pointer dereference.
--
G. Branden Robinson | Never underestimate the power of
Debian GNU/Linux | human stupidity.
branden@debian.org | -- Robert Heinlein
http://people.debian.org/~branden/ |
Attachment:
signature.asc
Description: Digital signature