Re: Another Firefox 21.0 crash (new backtrace)
On Mon, Jun 03, 2013 at 12:15:43AM +0200, Dimitry Andric wrote: On Jun 2, 2013, at 23:31, Ted Faber fa...@lunabase.org wrote: On Sun, Jun 02, 2013 at 05:35:27PM +0200, Dimitry Andric wrote: As a better fix, please try dropping the attached file into the /usr/ports/www/firefox/files directory, then rebuild the firefox port from scratch, and reinstall it. That works as well - firefox runs with compat6x installed, but compliled with the patch to www/firefox . Thanks again for debugging this! Well, the mystery is not entirely solved, as Firefox does not crash with a similar failure on -current, even with the compat6x libc.so.6 installed, and without the patch to osfile_unix_allthreads.jsm. So *something* is different in the way multiple versions of libc.so are handled, when they are loaded into the same process. Kostik, maybe you have any idea? The same library of different version loaded into the process address space causes all sort of funny effects which are not very useful to investigate in the details. E.g., non-hidden private symbols both function and data types which are also present in the earlier library are resolved to the symbols from earlier library. The split definitely causes complicated and contradictory behaviour. In other words, if not loading libc.so.6 makes the process behave, I consider the case closed. pgpUwuiVftagM.pgp Description: PGP signature
Re: Another Firefox 21.0 crash (new backtrace)
On May 29, 2013, at 05:53, Ted Faber fa...@lunabase.org wrote: On Tue, May 28, 2013 at 08:52:35AM -0700, Ted Faber wrote: On Tue, May 28, 2013 at 02:00:00PM +0200, Dimitry Andric wrote: 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). ... OK, I improved my svn fu, pulled the tree, extracted the patch, applied it, made and installed world. Now I see different behavior, but no better. Still gets a SEGV, but a different trace. (Attached) Ok, I think I have figured out what the problem is: Firefox's JavaScript OSFile implementation loads libc.so.6 if it is available! That is, if you have the compat6x package installed, it loads /usr/local/lib/libc.so.6, even while /lib/libc.so.7 is already loaded. This wreaks havoc when it later tries to call libc functions via libffi, and the result is that it calls into a completely bogus PLT entry. Most of the time, this leads to a crash. So the easiest way to avoid the crash for now is to uninstall the compat6x package, and making sure there is no libc.so.6 in /usr/local/lib/compat. Then Firefox should start with no problems. As a better fix, please try dropping the attached file into the /usr/ports/www/firefox/files directory, then rebuild the firefox port from scratch, and reinstall it. -Dimitry patch-toolkit-components-osfile-osfile_unix_allthreads.jsm Description: Binary data ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Another Firefox 21.0 crash (new backtrace)
On Sun, Jun 02, 2013 at 05:35:27PM +0200, Dimitry Andric wrote: On May 29, 2013, at 05:53, Ted Faber fa...@lunabase.org wrote: On Tue, May 28, 2013 at 08:52:35AM -0700, Ted Faber wrote: On Tue, May 28, 2013 at 02:00:00PM +0200, Dimitry Andric wrote: 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). ... OK, I improved my svn fu, pulled the tree, extracted the patch, applied it, made and installed world. Now I see different behavior, but no better. Still gets a SEGV, but a different trace. (Attached) Ok, I think I have figured out what the problem is: Firefox's JavaScript OSFile implementation loads libc.so.6 if it is available! That is, if you have the compat6x package installed, it loads /usr/local/lib/libc.so.6, even while /lib/libc.so.7 is already loaded. This wreaks havoc when it later tries to call libc functions via libffi, and the result is that it calls into a completely bogus PLT entry. Most of the time, this leads to a crash. So the easiest way to avoid the crash for now is to uninstall the compat6x package, and making sure there is no libc.so.6 in /usr/local/lib/compat. Then Firefox should start with no problems. Removing the compat6x package does fix my problem. Thanks enormously. I'll reinstall and give your patch a try next, but this is clearly the right bug. Thanks enormously! -- http://www.lunabase.org/~faber Unexpected attachment? http://www.lunabase.org/~faber/FAQ.html#SIG pgpEzlXowhLRK.pgp Description: PGP signature
Re: Another Firefox 21.0 crash (new backtrace)
On Sun, Jun 02, 2013 at 05:35:27PM +0200, Dimitry Andric wrote: As a better fix, please try dropping the attached file into the /usr/ports/www/firefox/files directory, then rebuild the firefox port from scratch, and reinstall it. That works as well - firefox runs with compat6x installed, but compliled with the patch to www/firefox . Thanks again for debugging this! -- http://www.lunabase.org/~faber Unexpected attachment? http://www.lunabase.org/~faber/FAQ.html#SIG pgpMXPn_Y1zBX.pgp Description: PGP signature
Re: Another Firefox 21.0 crash (new backtrace)
On Jun 2, 2013, at 23:31, Ted Faber fa...@lunabase.org wrote: On Sun, Jun 02, 2013 at 05:35:27PM +0200, Dimitry Andric wrote: As a better fix, please try dropping the attached file into the /usr/ports/www/firefox/files directory, then rebuild the firefox port from scratch, and reinstall it. That works as well - firefox runs with compat6x installed, but compliled with the patch to www/firefox . Thanks again for debugging this! Well, the mystery is not entirely solved, as Firefox does not crash with a similar failure on -current, even with the compat6x libc.so.6 installed, and without the patch to osfile_unix_allthreads.jsm. So *something* is different in the way multiple versions of libc.so are handled, when they are loaded into the same process. Kostik, maybe you have any idea? -Dimitry ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Another Firefox 21.0 crash, here it does not crashes...
Interesting... here firefox 21.0 does not crashes I have been using it for more than a day, on youtube, google, bbc, terra, wikipedia...and it does not crash I have setted up 3 accounts=test1, test2, test3 password=test access is vnc address is vnctest.k1.com.br Be nice, upload is only 360Kb/sec System is 9,1 stable 251224 desktop is gnome 2.34 CPU is atlhon X3 455 Filesystem is ZFS ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Another Firefox 21.0 crash, here it does not crashes...
On Jun 2, 2013, at 00:30, Sergio de Almeida Lenzi lenzi.ser...@gmail.com wrote: Interesting... here firefox 21.0 does not crashes I have been using it for more than a day, on youtube, google, bbc, terra, wikipedia...and it does not crash I have setted up 3 accounts=test1, test2, test3 password=test access is vnc address is vnctest.k1.com.br Be nice, upload is only 360Kb/sec System is 9,1 stable 251224 desktop is gnome 2.34 CPU is atlhon X3 455 Filesystem is ZFS You left out an important detail: which arch? The crashes seem to occur only on i386, not on amd64. :-) -Dimitry ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Another Firefox 21.0 crash
In message 86li6woie6@gly.ath.cx, Joseph Mingrone writes: Ted Faber fa...@lunabase.org writes: gcc46 gives me a compilation error: /usr/ports/www/firefox/work/mozilla-release/xpcom/io/nsMultiplexInputStream .cpp: In member function 'virtual nsresult nsMultiplexInputStream::Seek(int32 _t, int64_t)': /usr/ports/www/firefox/work/mozilla-release/xpcom/io/nsMultiplexInputStream .cpp:532:86: error: no matching function for call to 'XPCOM_MIN(int64_t, __g nu_cxx::__enable_iftrue, double::__type)' /usr/ports/www/firefox/work/mozilla-release/xpcom/io/nsMultiplexInputStream .cpp:532:86: note: candidate is: ../../dist/include/nsAlgorithm.h:34:1: note: templateclass T const T XPCOM_MIN(const T, const T) I'm on 9.1-STABLE #0 r246915 and configured firefox as follows: Options: DBUS: off DEBUG: off GCONF: off GIO: off GNOMEUI: off GNOMEVFS2: off GSTREAMER: on LIBPROXY: off LOGGING: off OPTIMIZED_CFLAGS: off PGO: off WEBRTC: off ALSA: off OSS: on PULSEAUDIO: off With the xpcom patch and r251047 applied to libc, no joy here. It segfaults in .cerror (same as Ted Faber's fa...@lunabase.org previous post to ports@). I heard from someone that it does work on HEAD. I haven't tried it yet (my laptop is quad boot. Trying it this week might be pushing it for me but I'll give it a try over the next couple of weeks. I did try FF 22 beta. It too segfaults. Running it on my server system downstairs with DISPLAY=laptop:0 works (using a virgin ~/.mozilla and a ~/.mozilla copied from my laptop). Thinking that it might be because I use a UNIX domain socket (DISPLAY=:0) and not an Internet socket (DISPLAY=localhost:0) I did try the latter. It still segfaulted. I think this may be a timing issue as my laptop is a dual core hyperthreaded Intel I3 (2.4 GHz) while my main server system is an AMD X2 4600 (dual core, no hyperthreading, also 2.4 GHz), not to mention latency imposed because of the gigabit wire rather than memory-to-memory communication. I did try it on 1.6 GHz Pentium M laptop (single core) and it too segfaulted. I think the network latency does alter the timing enough to allow it to work. (And no, using synchronous X calls does nothing to help.) I've yet to recompile with debug symbols as it fails due to memory exhaustion. Debug symbols would be able to pinpoint where it's failing. Having said that, having worked on numerous multi-threaded applications, strange things happen when locking is not just right. I think there may be a bug in FF or in our libthr that is tickled under the right circumstances such as we see here. Running it over the wire seems to slow it down enough to avoid the problem. Processor speed and number of processors doesn't seem to mitigate the resulting segfault though. Until someone can build with -g and get a meaningful backtrace I think this one will be a bear to find. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Another Firefox 21.0 crash
Ted Faber fa...@lunabase.org writes: gcc46 gives me a compilation error: /usr/ports/www/firefox/work/mozilla-release/xpcom/io/nsMultiplexInputStream.cpp: In member function 'virtual nsresult nsMultiplexInputStream::Seek(int32_t, int64_t)': /usr/ports/www/firefox/work/mozilla-release/xpcom/io/nsMultiplexInputStream.cpp:532:86: error: no matching function for call to 'XPCOM_MIN(int64_t, __gnu_cxx::__enable_iftrue, double::__type)' /usr/ports/www/firefox/work/mozilla-release/xpcom/io/nsMultiplexInputStream.cpp:532:86: note: candidate is: ../../dist/include/nsAlgorithm.h:34:1: note: templateclass T const T XPCOM_MIN(const T, const T) I'm on 9.1-STABLE #0 r246915 and configured firefox as follows: Options: DBUS: off DEBUG: off GCONF: off GIO: off GNOMEUI: off GNOMEVFS2: off GSTREAMER: on LIBPROXY: off LOGGING: off OPTIMIZED_CFLAGS: off PGO: off WEBRTC: off ALSA: off OSS: on PULSEAUDIO: off Joseph ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Another Firefox 21.0 crash
Ted Faber fa...@lunabase.org writes: 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 r...@ylum.lunabase.org:/usr/obj/usr/src/sys/GENERIC i386 I had a 9.1-STABLE i368 (sources grabbed a few months ago) and I was seeing the same problems. flo on irc suggested trying with gcc46 and that worked. Just put USE_GCC = 4.6 in the port's makefile. Joseph ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Another Firefox 21.0 crash
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 r...@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 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Another Firefox 21.0 crash
On Tue, May 28, 2013 at 02:00:00PM +0200, Dimitry Andric wrote: 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). [ snip] 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? Attached. 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). My svn fu is weak. Any chance you can roll a quick patch for me? (Or better yet, tell me the appropriate hex to start from?) I'm happy to try it out. -- http://www.lunabase.org/~faber Unexpected attachment? http://www.lunabase.org/~faber/FAQ.html#SIG Thread 21 (Thread 2d8c1f00 (LWP 101544/StreamTrans #6)): #0 0x281bc2d3 in pthread_kill () from /lib/libthr.so.3 #1 0x281bb9d2 in pthread_kill () from /lib/libthr.so.3 #2 0x281be919 in pthread_cond_signal () from /lib/libthr.so.3 #3 0x2b383475 in PRP_NakedNotify () from /usr/local/lib/libplds4.so.1 #4 0x2b3842fa in PR_WaitCondVar () from /usr/local/lib/libplds4.so.1 #5 0x2b3843e7 in PR_Wait () from /usr/local/lib/libplds4.so.1 #6 0x29e13743 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #7 0x29e1388f in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #8 0x29e118c4 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #9 0x29dcbf68 in std::vectormozilla::plugins::IPCByteRange, std::allocatormozilla::plugins::IPCByteRange ::_M_fill_insert () from /usr/local/lib/firefox/libxul.so #10 0x29e10e30 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #11 0x2b38a59a in PR_CreateThread () from /usr/local/lib/libplds4.so.1 #12 0x281b3f1a in pthread_getprio () from /lib/libthr.so.3 #13 0x in ?? () Thread 15 (Thread 3678f880 (LWP 101644/HTML5 Parser)): #0 0x281bc2d3 in pthread_kill () from /lib/libthr.so.3 #1 0x281bb9d2 in pthread_kill () from /lib/libthr.so.3 #2 0x281be919 in pthread_cond_signal () from /lib/libthr.so.3 #3 0x2b384381 in PR_WaitCondVar () from /usr/local/lib/libplds4.so.1 #4 0x2b3843e7 in PR_Wait () from /usr/local/lib/libplds4.so.1 #5 0x29e10022 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #6 0x29e11898 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #7 0x29dcbf68 in std::vectormozilla::plugins::IPCByteRange, std::allocatormozilla::plugins::IPCByteRange ::_M_fill_insert () from /usr/local/lib/firefox/libxul.so #8 0x29e10e30 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #9 0x2b38a59a in PR_CreateThread () from /usr/local/lib/libplds4.so.1 #10 0x281b3f1a in pthread_getprio () from /lib/libthr.so.3 #11 0x in ?? () Thread 14 (Thread 36789200 (LWP 101643/Cache I/O)): #0 0x281bc2d3 in pthread_kill () from /lib/libthr.so.3 #1 0x281bb9d2 in pthread_kill () from /lib/libthr.so.3 #2 0x281be919 in pthread_cond_signal () from /lib/libthr.so.3 #3 0x2b384381 in PR_WaitCondVar () from /usr/local/lib/libplds4.so.1 #4 0x2b3843e7 in PR_Wait () from /usr/local/lib/libplds4.so.1 #5 0x29e10022 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #6 0x29e11898 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #7 0x29dcbf68 in std::vectormozilla::plugins::IPCByteRange, std::allocatormozilla::plugins::IPCByteRange ::_M_fill_insert () from /usr/local/lib/firefox/libxul.so #8 0x29e10e30 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #9 0x2b38a59a in PR_CreateThread () from /usr/local/lib/libplds4.so.1 #10 0x281b3f1a in pthread_getprio () from /lib/libthr.so.3 #11 0x in ?? () Thread 13 (Thread 2d8c3080 (LWP 101642/DOM Worker)): #0 0x282a854b in strcasecmp_l () from /lib/libc.so.7 #1 0x282a8666 in strcasecmp () from /lib/libc.so.7 #2 0x282d195e in .cerror () from /lib/libc.so.7 #3 0x283477b8 in .got () from /usr/local/lib/libffi.so.6 #4 0x28345e87 in ffi_call_SYSV () from /usr/local/lib/libffi.so.6 #5 0x28345cbe in ffi_call () from /usr/local/lib/libffi.so.6 #6 0x2a6c295b in js::SizeOfDataIfCDataObject () from /usr/local/lib/firefox/libxul.so #7 0x2a41d167 in js::AutoMaybeTouchDeadZones::~AutoMaybeTouchDeadZones () from /usr/local/lib/firefox/libxul.so #8 0x2a3ec016 in js::AutoCTypesActivityCallback::AutoCTypesActivityCallback () from /usr/local/lib/firefox/libxul.so #9 0x2a41d127 in js::AutoMaybeTouchDeadZones::~AutoMaybeTouchDeadZones () from /usr/local/lib/firefox/libxul.so #10 0x2a41969f in
Re: Another Firefox 21.0 crash (new backtrace)
On Tue, May 28, 2013 at 08:52:35AM -0700, Ted Faber wrote: On Tue, May 28, 2013 at 02:00:00PM +0200, Dimitry Andric wrote: 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). [ snip] 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? Attached. 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). My svn fu is weak. Any chance you can roll a quick patch for me? (Or better yet, tell me the appropriate hex to start from?) I'm happy to try it out. OK, I improved my svn fu, pulled the tree, extracted the patch, applied it, made and installed world. Now I see different behavior, but no better. Still gets a SEGV, but a different trace. (Attached) Any ideas? -- http://www.lunabase.org/~faber Unexpected attachment? http://www.lunabase.org/~faber/FAQ.html#SIG Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 2d8c8e00 (LWP 100778/DOM Worker)] 0x282d19d0 in .cerror () from /lib/libc.so.7 (gdb) where #0 0x282d19d0 in .cerror () from /lib/libc.so.7 #1 0x3612ab00 in ?? () #2 0x in ?? () (gdb) thread apply all bt Thread 19 (Thread 36d0a200 (LWP 100783/StreamTrans #4)): #0 0x281bc313 in pthread_kill () from /lib/libthr.so.3 #1 0x281bba12 in pthread_kill () from /lib/libthr.so.3 #2 0x281be959 in pthread_cond_signal () from /lib/libthr.so.3 #3 0x2b383475 in PRP_NakedNotify () from /usr/local/lib/libplds4.so.1 #4 0x2b3842fa in PR_WaitCondVar () from /usr/local/lib/libplds4.so.1 #5 0x2b3843e7 in PR_Wait () from /usr/local/lib/libplds4.so.1 #6 0x29e13743 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #7 0x29e1388f in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #8 0x29e118c4 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #9 0x29dcbf68 in std::vectormozilla::plugins::IPCByteRange, std::allocatormozilla::plugins::IPCByteRange ::_M_fill_insert () from /usr/local/lib/firefox/libxul.so #10 0x29e10e30 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #11 0x2b38a59a in PR_CreateThread () from /usr/local/lib/libplds4.so.1 #12 0x281b3f4a in pthread_getprio () from /lib/libthr.so.3 #13 0x in ?? () Thread 15 (Thread 362f5600 (LWP 100780/HTML5 Parser)): #0 0x281bc313 in pthread_kill () from /lib/libthr.so.3 #1 0x281bba12 in pthread_kill () from /lib/libthr.so.3 #2 0x281be959 in pthread_cond_signal () from /lib/libthr.so.3 #3 0x2b384381 in PR_WaitCondVar () from /usr/local/lib/libplds4.so.1 #4 0x2b3843e7 in PR_Wait () from /usr/local/lib/libplds4.so.1 #5 0x29e10022 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #6 0x29e11898 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #7 0x29dcbf68 in std::vectormozilla::plugins::IPCByteRange, std::allocatormozilla::plugins::IPCByteRange ::_M_fill_insert () from /usr/local/lib/firefox/libxul.so #8 0x29e10e30 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #9 0x2b38a59a in PR_CreateThread () from /usr/local/lib/libplds4.so.1 #10 0x281b3f4a in pthread_getprio () from /lib/libthr.so.3 #11 0x in ?? () Thread 14 (Thread 362bef80 (LWP 100779/Cache I/O)): #0 0x281bc313 in pthread_kill () from /lib/libthr.so.3 #1 0x281bba12 in pthread_kill () from /lib/libthr.so.3 #2 0x281be959 in pthread_cond_signal () from /lib/libthr.so.3 #3 0x2b384381 in PR_WaitCondVar () from /usr/local/lib/libplds4.so.1 #4 0x2b3843e7 in PR_Wait () from /usr/local/lib/libplds4.so.1 #5 0x29e10022 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #6 0x29e11898 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #7 0x29dcbf68 in std::vectormozilla::plugins::IPCByteRange, std::allocatormozilla::plugins::IPCByteRange ::_M_fill_insert () from /usr/local/lib/firefox/libxul.so #8 0x29e10e30 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #9 0x2b38a59a in PR_CreateThread () from /usr/local/lib/libplds4.so.1 #10 0x281b3f4a in pthread_getprio () from /lib/libthr.so.3 #11 0x in ?? () Thread 13 (Thread 2d8c8e00 (LWP 100778/DOM Worker)): #0 0x282d19d0 in .cerror () from /lib/libc.so.7 #1 0x3612ab00 in ?? () #2 0x in ?? () Thread 11 (Thread 2d8c5e80 (LWP 100776/Timer)): #0 0x281bc313 in pthread_kill () from /lib/libthr.so.3 #1 0x281bba12 in pthread_kill () from /lib/libthr.so.3 #2
Re: Another Firefox 21.0 crash
In message 20130525230731.ga93...@mail.lunabase.org, Ted Faber writes: --O5XBE6gyVG5Rl6Rj Content-Type: multipart/mixed; boundary=YZ5djTAD1cGYuMQK Content-Disposition: inline --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. =20 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 r...@ylum.lunabase.org:/usr/obj/usr/src/sys/GENERI= C 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. Let me know if you have any suggestions. No suggestions. Just a me too. Compiling with -g results in address space memory exhaustion. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Another Firefox 21.0 crash
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 r...@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. Let me know if you have any suggestions. -- http://www.lunabase.org/~faber Unexpected attachment? http://www.lunabase.org/~faber/FAQ.html#SIG ylum:~$ firefox Multiple segmentation faults occurred; can't display error dialog ylum:~$ gdb `which firefox` GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd...(no debugging symbols found)... (gdb) run Starting program: /usr/local/bin/firefox (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New LWP 100663] (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New Thread 28501080 (LWP 100663/firefox)] (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols
