Created attachment 732396 [details] GDB stack trace Recently SeaMonkey has gotten quite unstable on Gentoo. I don't remember exactly at which version this started, but at least once per day (that is over some hours of usage) it crashes with "segmentation fault in raise () from /lib64/libpthread.so.0". Sometimes this happens when I'm navigating or writing an e-mail, sometimes it happens unattended when I'm not using it. A GDB stack trace is attached. Unfortunately, only SM was compiled with debugging symbols, so I don't know how useful the trace might be...
Which SeaMonkey version was this? Please post the bottom two lines from the "Help → About SeaMonkey" page. In the version I use, they look like this: User agent: Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20a1 Build identifier: 20130402003001 Yours is probably not exactly identical but it ought to be "recognizably similar".
Here it is (latest stable Gentoo build): User agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16.2 Build identifier: 20130330224958
(In reply to sphakka from comment #2) > Here it is (latest stable Gentoo build): > > User agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 > Firefox/19.0 SeaMonkey/2.16.2 > Build identifier: 20130330224958 Thanks. Now: - Do you get the same error with the SeaMonkey 2.16.2 from http://releases.mozilla.org/pub/mozilla.org/seamonkey/releases/2.16.2/contrib/seamonkey-2.16.2.en-US.linux-x86_64.tar.bz2 ? You can install it as follows: 1. Download it anywhere convenient 2. (from a root console) tar -xjvC /usr/local -f seamonkey-2.16.2.en-US.linux-x86_64.tar.bz2 pushd /usr/local/bin ln -sv ../seamonkey/seamonkey popd This installs a link to the "Mozilla" SeaMonkey as /usr/local/bin/seamonkey, which should be earlier in the $PATH than the "Gentoo" SeaMonkey. Your profile (containing your Preferences, your extensions if any, etc.) isn't touched by the operation. If you don't get the bug with this build, it will mean it's a Gentoo bug, which should be reported at Gentoo. If you do, this version of SeaMonkey can send crash data (about the crash, not personal identification about you) to Mozilla (please type a message about the crash in the crash reporter popup, even if it's only "while I was away sleeping"), and then, on browser restart, you can browse to about:crashes and paste into a bug comment the bp-something name of the link to the crash, which will have symbols for almost all its procedures, or at least for all the "interesting" ones.
The Mozilla build also crashed :-( here's the report: https://crash-stats.mozilla.com/report/index/bp-6d6e7017-cd16-4342-bd7e-b25cf2130403
Hm, in new report crash is inside system library, which not present in first GDB dump. Also, there is no other crashes with same signature within 4 weeks range. Anyway, now you need to test two more builds, current release 2.17 - http://releases.mozilla.org/pub/mozilla.org/seamonkey/releases/2.17/contrib/seamonkey-2.17.en-US.linux-x86_64.tar.bz2 and if it crashes too, then current nightly build from http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-comm-central-trunk/seamonkey-2.20a1.en-US.linux-x86_64.tar.bz2
(In reply to sphakka from comment #4) > The Mozilla build also crashed :-( Here are the details of the crash (which won't stay forever at crash-stats.mozilla.com). Signature libfontconfig.so.1.4.4@0x226d1 More Reports Search UUID 6d6e7017-cd16-4342-bd7e-b25cf2130403 Date Processed 2013-04-03 15:27:59 Uptime 27176 Install Age 7.5 hours since version was first installed. Install Time 2013-04-03 07:56:04 Product SeaMonkey Version 2.16.2 Build ID 20130310201053 Release Channel release OS Linux OS Version 0.0.0 Linux 3.7.10-gentoo #2 SMP PREEMPT Fri Mar 15 15:54:23 CET 2013 x86_64 Build Architecture amd64 Build Architecture Info family 15 model 72 stepping 2 Crash Reason SIGSEGV Crash Address 0x0 User Comments SeaMonkey crashed while writing an e-mail. App Notes OpenGL: VMware, Inc. -- Gallium 0.4 on softpipe -- 2.1 Mesa 9.0.1 -- texture_from_pixmap WebGL? libGL.so.1? libGL.so.1+ GL Context? GL Context+ WebGL+ Processor Notes sp-processor03.phx1.mozilla.com_8957:2008; exploitablity tool: ERROR: unable to analyze dump EMCheckCompatibility True Winsock LSP Adapter Vendor ID Adapter Device ID Bugzilla - Report this bug in SeaMonkey, Core, Plug-Ins, or Toolkit Crashing Thread Frame Module Signature Source 0 libfontconfig.so.1.4.4 libfontconfig.so.1.4.4@0x226d1 1 libfontconfig.so.1.4.4 libfontconfig.so.1.4.4@0x2284f 2 libxul.so gfxFcFontSet::Release gfx/thebes/gfxPangoFonts.cpp:1179 3 libxul.so nsTArray<gfxPangoFontGroup::FontSetByLangEntry, nsTArrayDefaultAllocator>::Destr gfx/thebes/gfxPangoFonts.h:65 4 libxul.so nsTArray<gfxPangoFontGroup::FontSetByLangEntry, nsTArrayDefaultAllocator>::Remov dist/include/nsTArray.h:944 5 libxul.so nsTArray<gfxPangoFontGroup::FontSetByLangEntry, nsTArrayDefaultAllocator>::~nsTA dist/include/nsTArray.h:442 6 libxul.so gfxPangoFontGroup::~gfxPangoFontGroup dist/include/nsTArray.h:1367 7 libxul.so gfxPangoFontGroup::~gfxPangoFontGroup gfx/thebes/gfxPangoFonts.cpp:1912 8 libxul.so gfxTextRunFactory::Release dist/include/gfxFont.h:891 9 libxul.so nsFontMetrics::~nsFontMetrics gfx/src/nsFontMetrics.cpp:78 10 libxul.so nsFontMetrics::Release gfx/src/nsFontMetrics.h:43 11 libxul.so nsFontCache::Flush gfx/src/nsDeviceContext.cpp:217 12 libxul.so nsFontCache::Destroy gfx/src/nsDeviceContext.cpp:96 13 libxul.so nsDeviceContext::~nsDeviceContext gfx/src/nsDeviceContext.cpp:238 14 libxul.so nsDeviceContext::Release gfx/src/nsDeviceContext.h:26 15 libxul.so nsPresContext::~nsPresContext layout/base/nsPresContext.cpp:249 16 libxul.so nsPresContext::~nsPresContext layout/base/nsPresContext.cpp:314 17 libxul.so nsPresContext::Release layout/base/nsPresContext.cpp:324 18 libxul.so nsDOMPageTransitionEvent::~nsDOMPageTransitionEvent objdir/mozilla/js/xpconnect/src/GeneratedEvents.cpp:550 19 libxul.so nsDOMEvent::Release content/events/src/nsDOMEvent.cpp:116 20 libxul.so ReleaseSliceNow js/xpconnect/src/XPCJSRuntime.cpp:549 21 libxul.so XPCIncrementalReleaseRunnable::ReleaseNow js/xpconnect/src/XPCJSRuntime.cpp:607 22 libxul.so XPCIncrementalReleaseRunnable::Run js/xpconnect/src/XPCJSRuntime.cpp:638 23 libxul.so nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:627 24 libxul.so NS_ProcessNextEvent_P objdir/mozilla/xpcom/build/nsThreadUtils.cpp:238 25 libxul.so mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:82 26 libxul.so MessageLoop::Run ipc/chromium/src/base/message_loop.cc:208 27 libxul.so nsBaseAppShell::Run widget/xpwidgets/nsBaseAppShell.cpp:163 28 libxul.so nsAppStartup::Run toolkit/components/startup/nsAppStartup.cpp:290 29 libxul.so XREMain::XRE_mainRun toolkit/xre/nsAppRunner.cpp:3823 30 libxul.so XREMain::XRE_main toolkit/xre/nsAppRunner.cpp:3890 31 libxul.so XRE_main toolkit/xre/nsAppRunner.cpp:4084 32 seamonkey main suite/app/nsSuiteApp.cpp:173 33 libc-2.15.so libc-2.15.so@0x224bd 34 seamonkey nsGetterAddRefs<nsIFile>::operator nsIFile**
Status: UNCONFIRMED → NEW
Crash Signature: [@ libfontconfig.so.1.4.4@0x226d1] [@ gfxFcFontSet::Release]
Ever confirmed: true
sphakka: This crash seems to be different from the other one; I'm appropriating the bug because this one is documented "à la Mozilla". If you crash in raise() again, please open a new bug (preferably from the "Report this bug" link just above the stack trace on the crash-stats.mozilla.com page).
Summary: SeaMonkey-2.16.2: segmentation fault in raise () from /lib64/libpthread.so.0 → crash in libfontconfig
Update. I have SM-2.17 "Mozilla" running for a while without crashing, whereas SM-2.17 "Gentoo" crashed again, apparently in the same point. I'd like to debug it "à la Mozilla", but can't get to compile in the crash handler: could anybody please tell me if there's a configure/compilation switch to enable for that? Until that, I can't really tell if the bug is the same or not...
To compile SeaMonkey (or Thunderbird or Firefox or…), you need to get the source and install any needed compiling tools before you even start. See https://developer.mozilla.org/en-US/docs/Simple_SeaMonkey_build as a how-to page. Or do you mean something else? The bp-something link in about:crashes should link you to a page with, among others, a listing of the stack. For nightly and release builds, most addresses should have symbols. What I pasted in comment #6 was copied from your crash in comment #4 via the clipboard. I cannot tell you for sure how you get symbols for the Gentoo build (since I am on openSUSE); maybe you need to install some seamonkey-debuginfo package or something?
(In reply to Tony Mechelynck [:tonymec] from comment #9) > To compile SeaMonkey (or Thunderbird or Firefox or…), you need to get the > source and install any needed compiling tools before you even start. See > https://developer.mozilla.org/en-US/docs/Simple_SeaMonkey_build as a how-to > page. Well, Gentoo does all that dirty job for free ;-) But it looks like some debugging features are not exposed, or I'm just missing something. Basically, I don't know how to get that "about:crashes" feature... Let's see what Gentoo Devs can say (https://bugs.gentoo.org/show_bug.cgi?id=465434).
My guess is that they intentionally compile without Breakpad (the crash reporter) because it would report crashes *to Mozilla* which wouldn't be appropriate for a *Gentoo* build.
P.S. You might want to compare the last section of the about:buildconfig page ("Configure arguments") for parallel builds of SeaMonkey 2.17 from Gentoo and from Mozilla. But I suppose it wouldn't be very useful anyway, unless you plan on compiling SeaMonkey yourself (yeah, doing the dirty job yourself, and beware: it may take several hours and require a lot of memory: the linking of the libxul.so is particularly memory-hungry).
(In reply to Tony Mechelynck [:tonymec] from comment #11) > My guess is that they intentionally compile without Breakpad (the crash > reporter) because it would report crashes *to Mozilla* which wouldn't be > appropriate for a *Gentoo* build. Right, indeed Gentoo configures SM by default with "--disable-crashreporter". I can easily tweak the configure script to avoid that, but will first wait for them to have a look at a standard GDB backtrace.
Do you still see this crashes?
Whiteboard: closeme INCO 2013-09-01
(In reply to Phoenix from comment #14) > Do you still see this crashes? I just installed SM-2.20, after a long break using FireFox. For now it looks fine, but I guess a couple days more of heavy usage will confirm it.
Everything fine so far. I close this.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.