Firefox carsh with: /usr/libexec/mozilla-launcher: line 117: 32619 Segmentation fault "$mozbin" "$@" with McAfee SiteAdvisor plugin installed. This does not happen with firefox-bin. CFLAGS="-march=pentium-m -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CXXFLAGS="${CFLAGS}" MAKEOPTS="-j2" Please let me know what other information might be usefull.
I have this behavior as well. I am having a hard time getting a useful backtrace though -- it seems that the nspr ebuild doesn't have a debug USE flag to enable debugging symbols (At least that is what I _think_ is going wrong). If I download firefox directly from mozilla.com and use LD_LIBRARY_PATH to load the precompiled libraries in mozilla's tar.gz package everything works fine, but if I don't set LD_LIBRARY_PATH then the directly downloaded binary package loads libraries from /usr/lib/mozilla-firefox and continues to segfault. Here is the best backtrace I've been able to get so far: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1220483408 (LWP 21125)] 0xb75bb528 in strcmp () from /lib/libc.so.6 (gdb) bt #0 0xb75bb528 in strcmp () from /lib/libc.so.6 #1 0xb7dfa6dc in PL_strcmp () from /usr/lib/nspr/libplc4.so.6 #2 0xdadadada in ?? () #3 0x0872f470 in ?? () #4 0xb7eb1874 in nsXPTCStubBase::QueryInterface () from /usr/lib/mozilla-firefox/libxpcom_core.so #5 0xb68df3bc in ?? () from /usr/lib/mozilla-firefox/components/libjar50.so #6 0x0872ee2c in ?? () #7 0x0872f378 in ?? () #8 0x0872f3ac in ?? () #9 0xb740a7e4 in ?? () from /usr/lib/mozilla-firefox/components/libxpconnect.so #10 0xbfd92950 in ?? () #11 0x00000000 in ?? () If anyone can instruct me how to figure out what to re-emerge (and how, in the case of NSPR) with debug symbols I'd be happy to do so. I can also post a strace log if that would be helpful. Steps I've taken to try to fix this: emerge --empty-tree mozilla-firefox revdep-rebuild Regards, Sam CFLAGS="-O2 -fomit-frame-pointer -march=athlon-xp -pipe" CHOST="i686-pc-linux-gnu" CXXFLAGS="-O2 -fomit-frame-pointer -march=athlon-xp -pipe" MAKEOPTS="-j2"
which versions of nss/nspr/firefox (all the latest ~arch here) I could not reproduce it with site-advisor 23.0, although it seems to make loading just google a major PITA - slowing it down to crawl, but there are no segfaults
Hi Gergan, Thanks for looking into this. Here are the versions and use flags: laptop ~ # emerge -pv nss nspr mozilla-firefox These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] dev-libs/nss-3.11.3 0 kB [ebuild R ] dev-libs/nspr-4.6.3 USE="ipv6" 0 kB [ebuild R ] www-client/mozilla-firefox-1.5.0.7 USE="debug gnome ipv6 -java -mozdevelop -xinerama -xprint" LINGUAS="en_GB -ar -bg -ca -cs -da -de -el -es -es_AR -es_ES -eu -fi -fr -ga -ga_IE -gu_IN -he -hu -it -ja -ko -lt -mk -nb -nb_NO -nl -pa_IN -pl -pt_BR Regards, Sam
hm could you test dev-libs/nspr-4.6.3-r1 from ChangeLog 10 Oct 2006; Robin H. Johnson <robbat2@gentoo.org> +nspr-4.6.3-r1.ebuild: Bug #150731, use_enable debug to fix an upstream crash. and dev-libs/nss-3.11.3-r1 These are the ones, which I have installed.
I've emerged the new versions and am still getting crashes. I had hoped the addition of a debug use flag to NSPR would have improved the backtrace but no such luck. Should I recompile without debug enabled? Here is my new backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1220806992 (LWP 20940)] 0xb756c528 in strcmp () from /lib/libc.so.6 (gdb) bt #0 0xb756c528 in strcmp () from /lib/libc.so.6 #1 0xb7dac6dc in PL_strcmp () from /usr/lib/nspr/libplc4.so.6 #2 0xdadadada in ?? () #3 0x086ea2a0 in ?? () #4 0xb7e63874 in nsXPTCStubBase::QueryInterface () from /usr/lib/mozilla-firefox/libxpcom_core.so #5 0xb68903bc in ?? () from /usr/lib/mozilla-firefox/components/libjar50.so #6 0x086e9acc in ?? () #7 0x086ea2b8 in ?? () #8 0x086ea02c in ?? () #9 0xb73bb7e4 in ?? () from /usr/lib/mozilla-firefox/components/libxpconnect.so #10 0xbf9bcd80 in ?? () #11 0x00000000 in ?? () Regards, Sam
I'm emerging debugedit and emerging libc, nss, nspr and mozilla-firefox with debug flags and FEATURES="installsources nostrip" enabled. Hopefully tomorrow I'll be able to get a more meaningful backtrace. Sam
this needs to be tested with -bin before mozilla herd investigates.
Ok, here is a slightly more useful backtrace. Unfortunately it looks like the crash is buried in some javascript code that has something to do with handling .jar files -- I don't know enough to know how to get GDB to give any meaningful information about what javascript is being run. (gdb) bt #0 0xb75cb528 in strcmp () from /lib/libc.so.6 #1 0xb7e0a6cc in PL_strcmp (a=0xdadadada <Address 0xdadadada out of bounds>, b=0xdadadada <Address 0xdadadada out of bounds>) at strcmp.c:47 #2 0xb68eb6de in nsZipArchive::FindNext (this=0x8744874, aFind=0x8744d98, aResult=0xdadada00) at nsZipArchive.cpp:802 #3 0xb68ef3bc in nsJAREnumerator::HasMoreElements (this=0x8774ce8, aResult=0xbfadbf60) at nsJAR.cpp:995 #4 0xb7ed0f59 in XPTC_InvokeByIndex () at xptcstubs_gcc_x86_unix.cpp:49 #5 0xb73f8b7b in XPCWrappedNative::CallMethod (ccx=@0xbfadc040, mode=XPCWrappedNative::CALL_METHOD) at xpcwrappednative.cpp:2155 #6 0xb7401f74 in XPC_WN_CallMethod (cx=0x8554a40, obj=0xdadada00, argc=3671775744, argv=0x87bfe10, vp=0xdadada00) at xpcwrappednativejsops.cpp:1445 #7 0xb7f550e0 in js_Invoke (cx=0x8554a40, argc=0, flags=0) at jsinterp.c:1187 #8 0xb7f49cca in js_Interpret (cx=0x8554a40, pc=0x874471a ":", result=0xbfadc50c) at jsinterp.c:3583 #9 0xb7f55248 in js_Invoke (cx=0x8554a40, argc=0, flags=0) at jsinterp.c:1207 #10 0xb7f49cca in js_Interpret (cx=0x8554a40, pc=0x874bff3 ":", result=0xbfadc8d0) at jsinterp.c:3583 #11 0xb7f544a2 in js_Execute (cx=0x8554a40, chain=0x8393f90, script=0x874bfb8, down=0x0, flags=3671775744, result=0xdadada00) at jsinterp.c:1433 #12 0xb7f0ff7a in JS_ExecuteScript (cx=0x8554a40, obj=0xdadada00, script=0xdadada00, rval=0xdadada00) at jsapi.c:4027 #13 0xb6436ab5 in nsJSContext::ExecuteScript (this=0x8553fe0, aScriptObject=0xdadada00, aScopeObject=0x8393f90, aRetValue=0x0, aIsUndefined=0x0) at nsJSEnvironment.cpp:1218 #14 0xb6407459 in nsXULDocument::ExecuteScript (this=0x8437ba0, aScriptObject=0x87ba5b8) at nsXULDocument.cpp:3566 #15 0xb6411354 in nsXULDocument::OnStreamComplete (this=0x8437ba0, aLoader=0x87735c8, context=0x0, aStatus=0, stringLen=141839744, string=0x8744d80 "content/oem.txt") at nsXULDocument.cpp:3460 #16 0xb72aa88a in nsStreamLoader::OnStopRequest (this=0x87735c8, request=0xdadada00, ctxt=0x0, aStatus=141839744) at nsStreamLoader.cpp:132 #17 0xb68f9ec1 in nsJARChannel::OnStopRequest (this=0x8773950, req=0x8773c38, ctx=0x0, status=0) at nsJARChannel.cpp:711 #18 0xb727bf53 in nsInputStreamPump::OnStateStop (this=0x8773c38) at nsInputStreamPump.cpp:506 #19 0xb727c084 in nsInputStreamPump::OnInputStreamReady (this=0x8773c38, stream=0x8773cd4) at nsInputStreamPump.cpp:343 #20 0xb7e86535 in nsInputStreamReadyEvent::EventHandler (plevent=0xdadada00) at nsStreamUtils.cpp:119 #21 0xb7ea630b in PL_HandleEvent (self=0x8773ffc) at plevent.c:688 #22 0xb7ea6d90 in PL_ProcessPendingEvents (self=0x80e3fa0) at plevent.c:623 #23 0xb7ea95dd in nsEventQueueImpl::ProcessPendingEvents (this=0x81180e0) at nsEventQueue.cpp:417 #24 0xb68b9715 in event_processor_callback (source=0x8598468, condition=G_IO_IN, data=0x8744d80) at nsAppShell.cpp:67 #25 0xb78ee4d0 in g_vasprintf () from /usr/lib/libglib-2.0.so.0 #26 0x08598468 in ?? () #27 0x00000001 in ?? () #28 0x085984b0 in ?? () #29 0xb7927354 in ?? () from /usr/lib/libglib-2.0.so.0 #30 0x00000000 in ?? () Regards, Sam
Just incase the original reporter's bug is different from mine, I am confirming that firefox-bin does not exhibit this problem and functions normally with siteadvisor.com's plugin installed. I am a bit beyond my depth as far as mozilla/gdb debugging goes, but if there are any gdb commands that would be useful based on my last backtrace I'd be happy to keep my debug files installed and help get to the bottom of this. Regards, Sam
well this seems relevant to me: #0 0xb75cb528 in strcmp () from /lib/libc.so.6 #1 0xb7e0a6cc in PL_strcmp (a=0xdadadada <Address 0xdadadada out of bounds>, b=0xdadadada <Address 0xdadadada out of bounds>) at strcmp.c:47 #2 0xb68eb6de in nsZipArchive::FindNext (this=0x8744874, aFind=0x8744d98, aResult=0xdadada00) at nsZipArchive.cpp:802 #3 0xb68ef3bc in nsJAREnumerator::HasMoreElements (this=0x8774ce8, aResult=0xbfadbf60) at nsJAR.cpp:995 also PL_strcmp just checks for null-pointers and then delegates to glibc, which could not compare the strings because the pointers are invalid, now one of the possibilities is problem with gentoo zlib - you could try building with the firefox-bundled zlib - remove the line "--with-system-zlib \" from the mozcoreconf.eclass and rebuild firefox or another possibility is to update the zlib to the latest ~arch. Also a strace probably could show you on which file this is happening.
Strace shows this segfault happening while or shortly after reading data from safe.jar in the siteadvisor plugin directory. I will try your zlib-related rebuilding suggestions when I have some more time, probably tomorrow.
https://bugzilla.mozilla.org/show_bug.cgi?id=333423#c35 also it is a mozilla-bug but it is very strange as the patch should have been commited on 2006-09-13 and on 2006-09-14 was the 1.5.0.7 release... (but it is not present in the source - so what are the chances for mozilla building the binaries not from the official sources?).
This is very strange. That is likely exactly the bug I am seeing judgeing by the sequence of calls in the backtrace. The recognizable argument in the backtrace ("content/oem.txt") is directly from framework.js in safe.jar and appears to be set as the "search" value to a function that performs exactly the crash-inducing commands from the mozilla.org bug. But it seems to not effect everyone -- or maybe there is some obscure config flag that Mozilla uses for their official builds. Is there any plausible way to determine which sources the -bin versions are compiled from? BTW, I don't see the bug-fix checkin on the branch for 1.5.0.7 if I am using mozilla's LXR correctly. Regards, Sam
(In reply to comment #13) > But it seems to not effect everyone -- or maybe there is some obscure config well I was slightly incorrect - I have 24.0 and I didn't test 23.0 - I have had 23.0, but it was disabled, so I upgraded it and after that enabled it. So it could be that 23.0 is still crash happy. > flag that Mozilla uses for their official builds. Is there any plausible way to > determine which sources the -bin versions are compiled from? I'm afraid there is no way to say for sure, what for sources were used for the official build. > > BTW, I don't see the bug-fix checkin on the branch for 1.5.0.7 if I am using > mozilla's LXR correctly. well 1.5.0.7 is only release tag as far as I know, so there should be no more checkins after the tarball release (that's what I've looked in)... probably if you could confirm that the patch from mozilla works for you, the gentoo mozilla-herd could apply the patch to the patchset, as I don't think that 2.0 will go stable so soon...
Ok, compiling with that patch now by using "ebuild www-client/mozilla-firefox/mozilla-firefox-1.5.0.7 unpack" then patching then running "ebuild www-client/mozilla-firefox/mozilla-firefox-1.5.0.7 compile". If that goes well, I'll do the install/qmerge stuff manually as well and report back. I've also posted a comment on the mozilla bug posted here asking for clarification of this bug's status as of 1.5.0.7. Regards, Sam
Hmm! This is my third time trying to post confirmation that compiling with the mozilla.org patch (https://bugzilla.mozilla.org/attachment.cgi?id=237487). Anyways, the mozilla.org folks have confirmed that this patch isn't applied to the 1.5.0.7 codebase so I still have no idea why the -bin releases don't exhibit the same problem. I guess the only remaining point to debate would be whether applying this patch would get gentoo into similar troubles as debian seems to be having with trying to maintain non-binary releases. Regards, Sam
McAffee has a new version of siteadvisor upcoming that has fixed this bug from their end.
Fixed upstream via Anarchy.
