From owner-freebsd-current@FreeBSD.ORG Mon Oct 6 05:14:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2477E10656A1 for ; Mon, 6 Oct 2008 05:14:04 +0000 (UTC) (envelope-from jos@catnook.com) Received: from lizzy.dyndns.org (209-204-188-132.dsl.static.sonic.net [209.204.188.132]) by mx1.freebsd.org (Postfix) with SMTP id D70D28FC1F for ; Mon, 6 Oct 2008 05:14:03 +0000 (UTC) (envelope-from jos@catnook.com) Received: (qmail 6310 invoked by uid 1000); 6 Oct 2008 05:14:24 -0000 Date: Sun, 5 Oct 2008 22:14:24 -0700 From: Jos Backus To: Tim Kientzle Message-ID: <20081006051424.GA5858@lizzy.catnook.local> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48E95D0E.50202@freebsd.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Andrey Chernov , freebsd-current@freebsd.org Subject: Re: firefox3-bin crashes near arc4random_buf() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jos@catnook.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2008 05:14:04 -0000 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