Date: Sun, 5 Oct 2008 22:14:24 -0700 From: Jos Backus <jos@catnook.com> To: Tim Kientzle <kientzle@freebsd.org> Cc: Andrey Chernov <ache@nagual.pp.ru>, freebsd-current@freebsd.org Subject: Re: firefox3-bin crashes near arc4random_buf() Message-ID: <20081006051424.GA5858@lizzy.catnook.local> In-Reply-To: <48E95D0E.50202@freebsd.org> References: <20081004080511.GA72641@lizzy.catnook.local> <20081004161024.GA67323@nagual.pp.ru> <20081004222249.GA48928@lizzy.catnook.local> <48E80F02.4070309@freebsd.org> <20081005233256.GB8507@lizzy.catnook.local> <48E95D0E.50202@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Oct 05, 2008 at 05:34:22PM -0700, Tim Kientzle wrote: > > This to me suggests that the segfault happens inside _umtx_op. Am I reading > > that correctly? > > Not necessarily. Firefox is multi-threaded. The thread that > called _umtx_op() is not the thread that crashed (_umtx_op() > hadn't returned to userspace, so that thread was still in > the kernel). > > This does, however, answer one puzzle: Firefox appears to > have a signal handler that catches SEGV, releases the lock > file, then re-throws SEGV to actually kill the program. > That explains stack frames #0-#4 in your backtrace; that's > the signal handler executing after the segfault but before > the program is terminated. Understood. > Something is still screwy about the backtrace. dbopen() > doesn't call arc4random_buf. However, it does call > mkstemp() which does call arc4random_uniform, which should > be right next to arc4random_buf in memory. GCC optimizations > could be obscuring the call stack here. > > It's certainly possible that arc4random is involved > somehow but I don't yet see it. It does seem likely > that we're looking at a libc problem, so a debug > version of libc might help. Replacing libc on a > running system is a little tricky. I believe the > following works, though I've not tried it: > > % cd /usr/src/lib/libc > % make clean > % make DEBUG_FLAGS=-g > % cp /lib/libc.so.7 /lib/libc.so.7-backup > ... reboot to single user, use /rescue/sh as your shell ... > % cp /usr/src/lib/libc/libc.so.7 /lib/libc.so.7 chflags noschg /lib/libc.so.7 /rescue/cp /usr/obj/usr/src/lib/libc/libc.so.7 /lib/libc.so.7 > ... reboot ... > > This should give you a standard libc with full > debugging symbols. Hopefully, the backtrace will > now give more details. > > I think we're getting closer. Yeah. Oddly enough the debug version seems to make a difference; firefox3 hasn't crashed yet. Normally even without touching it firefox3 will segfault within an hour or so. I will leave it up all night to see what happens. Thanks, Tim. I'll keep you posted. -- Jos Backus jos at catnook.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081006051424.GA5858>