On Sat 2013-04-13 13:01:46 -0400, Guido Günther wrote: > gdb's "thread apply all bt full" might give further hints. The nspr > code itself didn't change since ages so we ought to find out what > triggers it. Sorry about being that vague.
well, the segv just happened again with the following backtrace:
(gdb) bt
#0 pt_PostNotifyToCvar (cvar=0x0, broadcast=broadcast@entry=0)
at ptsynch.c:280
#1 0x00007ffff6301b5b in PR_NotifyCondVar (cvar=<optimized out>)
at ptsynch.c:413
#2 0x00007ffff6309709 in ProcessReapedChildInternal (pid=pid@entry=31879,
status=<optimized out>) at uxproces.c:531
#3 0x00007ffff6309d27 in WaitPidDaemonThread (unused=<optimized out>)
at uxproces.c:658
#4 0x00007ffff630729c in _pt_root (arg=0x7fffab7ff450) at ptthread.c:191
#5 0x00007ffff743ab50 in start_thread (arg=<optimized out>)
at pthread_create.c:304
#6 0x00007ffff7184a7d in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#7 0x0000000000000000 in ?? ()
(gdb)
i've got a "thread apply all bt full" dump, but it's > 4K lines, and i
haven't had a chance to review it in detail for sensitive content to see
if i can post the whole thing. if you can suggest what to look for, i'd
be happy to do a skim of the relevant parts and try to report back.
what should i be looking for?
--dkg
pgpy66uwBFfK6.pgp
Description: PGP signature
