Date: Tue, 28 May 2013 14:00:00 +0200 From: Dimitry Andric <dim@FreeBSD.org> To: Ted Faber <faber@lunabase.org>, freebsd-ports@freebsd.org Cc: Kostik Belousov <kostikbel@gmail.com> Subject: Re: Another Firefox 21.0 crash Message-ID: <51A49C40.1080209@FreeBSD.org> In-Reply-To: <20130525230731.GA93415@mail.lunabase.org> References: <20130525230731.GA93415@mail.lunabase.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2013-05-26 01:07, Ted Faber wrote: > I'm seeing a repeatable, consistent segmentation fault before the first > window appears (though firefox -ProfileManager brings up the > profile manager, but crashes when I try to actually start the browser). > > I've deleted ~/.mozilla and just about everything I can think to get rid > of. > > The system is a 9.1 i386 system: > FreeBSD ylum.lunabase.org 9.1-STABLE FreeBSD 9.1-STABLE #28 r250528: Sat > May 11 17:19:54 PDT 2013 root@ylum.lunabase.org:/usr/obj/usr/src/sys/GENERIC i386 > > Firefox is built under the most recent clang port. Firefox options are > all the defaults (make rmconfig). > > I rebuilt all the ports from scratch within the last week. > > I've attached a gdb trace from just running the firefox binary under > gdb. I'm not sure I believe it, but clues are scarce on the ground. I > can get a ktrace if it will help. ... > (gdb) info threads > 19 Thread 36d0a200 (LWP 101008/StreamTrans #4) 0x281bc2d3 in pthread_kill () > from /lib/libthr.so.3 > 15 Thread 362f5600 (LWP 101652/HTML5 Parser) 0x281bc2d3 in pthread_kill () > from /lib/libthr.so.3 > 14 Thread 362c0f80 (LWP 101651/Cache I/O) 0x281bc2d3 in pthread_kill () > from /lib/libthr.so.3 > * 13 Thread 2d8c7e00 (LWP 101017/DOM Worker) 0x282a854b in strcasecmp_l () > from /lib/libc.so.7 > 11 Thread 2d8c4e80 (LWP 101007/Timer) 0x281bc2d3 in pthread_kill () > from /lib/libthr.so.3 > 10 Thread 28504c80 (LWP 101006/JS Watchdog) 0x281bc2d3 in pthread_kill () > from /lib/libthr.so.3 > 9 Thread 28504a00 (LWP 101005/firefox) 0x281bc2d3 in pthread_kill () > from /lib/libthr.so.3 > 8 Thread 28504780 (LWP 100838/JS GC Helper) 0x281bc2d3 in pthread_kill () > from /lib/libthr.so.3 > 7 Thread 28503380 (LWP 100836/Hang Monitor) 0x281bc2d3 in pthread_kill () > from /lib/libthr.so.3 > 6 Thread 28502e80 (LWP 100811/Socket Thread) 0x2826785b in poll () > from /lib/libc.so.7 > 5 Thread 2d860f80 (LWP 100810/XPCOM CC) 0x281bc2d3 in pthread_kill () > from /lib/libthr.so.3 > 4 Thread 28501d00 (LWP 100806/Gecko_IOThread) 0x282b030b in kevent () > from /lib/libc.so.7 > 3 Thread 28501f80 (LWP 100804/firefox) 0x2826785b in poll () > from /lib/libc.so.7 > 2 Thread 28501080 (LWP 100663/firefox) 0x2a4fc85b in js::StackSpace::sizeOf > () from /usr/local/lib/firefox/libxul.so Since it seems libthr.so is involved, and a lot of thread signalling is going on, I suspect r251047 may help here. It fixes a tricky problem with deferred signal delivery, and it looks like this is what you are experiencing here. Can you please do a backtrace of all threads (e.g. "thread apply all bt") too? Note that r251047 should apply cleanly to an up-to-date stable/9 tree, but you will have to rebuild and reinstall libc and libthr (or just build and install world). -Dimitry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51A49C40.1080209>