Another Firefox 21.0 crash

[Dimitry Andric]

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 at 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