857162 - crash in libfontconfig

Status: RESOLVED INVALID

(SeaMonkey :: General, defect)

Description

[sphakka]

Attachment: 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...

Comment 1

[Tony Mechelynck [:tonymec]]

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".

Comment 2

[sphakka]

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

Comment 3

[Tony Mechelynck [:tonymec]]

(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.

Comment 4

[sphakka]

The Mozilla build also crashed :-( here's the report: 

https://crash-stats.mozilla.com/report/index/bp-6d6e7017-cd16-4342-bd7e-b25cf2130403

Comment 5

[Phoenix]

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

Comment 6

[Tony Mechelynck [:tonymec]]

(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**

Comment 7

[Tony Mechelynck [:tonymec]]

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).

Comment 8

[sphakka]

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

Comment 9

[Tony Mechelynck [:tonymec]]

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?

Comment 10

[sphakka]

(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).

Comment 11

[Tony Mechelynck [:tonymec]]

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.

Comment 12

[Tony Mechelynck [:tonymec]]

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).

Comment 13

[sphakka]

(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.

Comment 14

[Phoenix]

Do you still see this crashes?

Comment 15

[sphakka]

(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.

Comment 16

[sphakka]

Everything fine so far. I close this.