750015 - Firefox/SeaMonkey crashes frequently with SIGSEGV in libpthread-2.11.1.so (Ubuntu Linux x86 32-bit))

Status: RESOLVED INVALID

(Core :: General, defect)

Description

[Andrew Poth]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120422 Firefox/12.0 SeaMonkey/2.9
Build ID: 20120422224137

Steps to reproduce:

Viewing Web page or loading new Web page.


Actual results:

SeaMonkey window suddenly closes.  Sometimes Crash Reporter doesn't appear.  On a few occasions the system locks up, requiring power-down, suggesting system was unable to catch SEGV memory violation.  The great majority of crash reports indicate problem with SIGSEGV in libpthread-2.11.1.so, the POSIX Thread library. Crash Address varies.  For example, see Crash Reports bp-60b3153e-fbe3-4b80-9669-0626e2120429 and bp-7238f0cc-a8db-4c9a-a49a-3e2782120429.  Crashes come in clusters, with SeaMonkey crashing repeatedly within 60 seconds to 10 minutes of previous crash, or crashing even as it is recovering from the previous crash.  I've had as many as five Crash Reporter instances active simultaneously.  At other times SeaMonkey may run for 20-30 hours without a hitch while viewing all kinds of Web content, including sites containing JavaScript, Java and Flash.  Firefox 11 is similarly affected.  Ubuntu 10.04.4 LTS operating system was installed from scratch in early March 2012, about 6 weeks ago, but this behavior was present in previous Ubuntu 10.04.1 LTS system as well for over a year through several releases of SeaMonkey 2.x.  No other Linux applications exhibit this problem, including graphics programs that use hundreds of megabytes of RAM and extensively exercise the hard disk drive.  I've tried running SeaMonkey in "safe mode", but there was no difference.  I've created alternate profiles with no plugins or extensions, and there hasn't been any difference either.  A full scan of RAM with memtest86+ didn't reveal any problems; all tests passed.


Expected results:

SeaMonkey should not have crashed.

Comment 1

[Philip Chee]

Are you Maniac42/sysop?
From <http://forums.mozillazine.org/viewtopic.php?p=11934719#p11934719>

"https://crash-stats.mozilla.com/query/query?product=SeaMonkey&version=SeaMonkey%3A2.8&platform=linux&range_value=3&range_unit=days&date=04%2F25%2F2012+18%3A51%3A46&query_search=signature&query_type=contains&query=&reason=&build_id=&process_type=any&hang_type=any&do_query=1
suggests that there's a crashy libpthread running around apparently one ubunutu user as all the crashes with those libpthread signatures have the same install time"

Actually there are now two users crashing:
<https://crash-stats.mozilla.com/report/list?signature=libpthread-2.11.1.so%400x9331>
Unless it's you who has just upgraded from SeaMonkey 2.8 to SeaMonkey 2.9.

From <http://forums.mozillazine.org/viewtopic.php?p=11939819#p11939819>

[quote]
22:06 mcsmurf sysop: do you use some alternative Java plugin?
22:07 Callek sysop: more specifically what Ubuntu version do you have?
22:07 sysop I'm running OpenJDK, the only plugin that's now available from the Canonical repositories, since Oracle "pulled the plug" on Sun Java last August. Canonical now only supplies OpenJDK for Ubuntu.
22:07 Callek oo already said, 10
22:07 sysop Ubuntu 10.04.4 LTS, 32-bin i386
22:07 mcsmurf yeah, I think that's the problem, their plugin has a bug
22:08 mcsmurf try this:
22:08 mcsmurf go to about:config
22:08 mcsmurf and change dom.ipc.plugins.java.enabled to true
22:09 mcsmurf this will run Java outside of SeaMonkey
22:09 sysop OK, I've done so.
22:09 mcsmurf so that only the plugin crashes, not SeaMonkey
22:09 mcsmurf some workaround
22:10 mcsmurf you might have to restart SeaMonkey, not sure
22:10 sysop When will I know if this workaround fixes it?
22:10 mcsmurf you don't crash anymore :D
22:10 mcsmurf then it worked
[/quote]

Comment 2

[Phoenix]

Andrew, does advice in Comment 1 helps you?

Comment 3

[Andrew Poth]

Yes, I post as "Maniac42" on Mozillazine.  I upgraded from SeaMonkey 2.8 to 2.9 in the meantime, but there has been no change or improvement in the libpthread-2.11.1.so related crash behavior.

The crashing behavior appears to be non-deterministic, i.e., random.  I recently found a discussion at http://stackoverflow.com/questions/1944602/segmentation-fault-when-using-pthreads-in-a-nondeterministic-manner that may be germane to this problem.

Comment 4

[Phoenix]

So, did you try to set dom.ipc.plugins.java.enabled to true?

Comment 5

[Andrew Poth]

Re: Comment #4

Yes, I did.  It didn't appear to make any difference whatsoever.  It also crashes just as frequently and unpredictably when running in safe-mode, so I presume Java isn't even loaded then, even if one encounters a page with Java content.

Comment 6

[Andrew Poth]

Checking crash reports, it appears that only SeaMonkey, Firefox and Thunderbird on Linux are exhibiting this behavior.  I rarely run Firefox, and even more rarely run Thunderbird, since SeaMonkey is my primary browser and email application.  I hardly see other applications crashing on my Ubuntu system; it usually happens after SeaMonkey has crashed several times, apparently corrupting memory and then causing other programs to crash or causing the entire operating system to hang.  The system is running on an AMD Athlon processor; I don't know if that has anything to do with it, since AMD's CPUs are supposedly 100% compatible with Intel CPUs.

This thing is behaving like an uninitialized or mis-initialized variable, or perhaps an off-by-one array pointer or variable that has inadvertently been reused, causing its value to be changed in an an unpredictable fashion.  It may be a single, stupid oversight in the umpteen-thousand lines of C code that is common to the 32-bit Linux builds of SeaMonkey, Firefox and Thunderbird.

Comment 7

[Andrew Poth]

This is not a Web page content issue.  Today I'm seeing SeaMonkey 2.9.1 crashing repeatedly when it's started up in mail client mode only.  I can also start up SeaMonkey; have it idling on a blank page, and within 15 minutes of startup it is likely to simply crash with a segmentation fault in libpthread-2.11.1.so.  The problem is entirely within the Firefox / Thunderbird / SeaMonkey common code.

The latest Firefox 13.0.1 pushed out by Canonical for Ubuntu 10.04 a couple of days ago has become totally unusable; even when one eventually succeeds in getting it to start in "safe mode" and displaying a blank page, it will only run for a few minutes before crashing with a random segmentation fault in libpthread-2.11.1.so.  It frequently hangs during restart with a futex_wait_queue_me in the waiting channel, a failure that NEVER gets reported by the Mozilla Crash Reporter.  I'm not going to attempt to install SeaMonkey later than 2.9.1 on the assumption that whatever badness has been baked into Firefox 13 for Linux is going to show up in SeaMonkey for Linux as well.

The problem with the way the Mozilla crash reports are gathered is that the libpthread library crashes are scattered over a wide range of memory addresses and versions of libpthread.  Because of this, the casual observer might be induced to believe that libpthread crashes on Linux are rare.  I don't think this is the case at all.  There are reports of libpthread-2.15.x.so crashes on AMD 64 systems, and I'd be willing to bet that it's the same thing that's going on with my AMD 32-bit system and libpthread-2.11.1.so.

I'll try starting up SeaMonkey again this evening around 9 p.m. or 10 p.m.  Chances are, it may stay up for two to four days without a hitch, as it has before, or it may crash before the program window appears.

(This comment was posted with Opera 12.00 build 1467 for Linux, since SeaMonkey has become essentially unusable at present.)

Comment 8

[Phoenix]

Can you provide also Firefox crash ids?
Also, I see that all crashes with your id happens on GeForce 5500 with 173.14.22 driver, but latest for this card is 173.14.31 and in it's release highlights written "Fixed a bug that caused freezes and crashes when resizing windows in KDE 4 with desktop effects enabled using X.Org X server version 1.10 or later.", could it be your case?

Comment 9

[Andrew Poth]

Here are some recent Firefox crash IDs.  They're in sequence and
all for libpthread-2.11.1.so --

bp-f914f236-c3c9-4e2c-8412-d742a2120627   06/26/2012 05:12 PM
bp-6f36e77e-aac7-4a80-8de3-3016a2120627   06/26/2012 05:12 PM
bp-52ed0f9a-c35e-410a-8b5a-f40782120627   06/26/2012 05:12 PM
bp-bd052991-eac7-400f-8cac-b47532120627   06/26/2012 05:12 PM
bp-37583c1e-9a12-438d-8a1d-6dc7d2120627   06/26/2012 05:03 PM
bp-3a23a99c-a32c-4644-a202-854182120627   06/26/2012 05:03 PM
bp-c5f54bcf-c4d3-4b7f-a1c4-5d83a2120627   06/26/2012 05:03 PM
bp-ee6beb08-f0e8-4e45-ad16-90e902120627   06/26/2012 05:02 PM
bp-439d6a07-78e1-4cba-a500-f414b2120627   06/26/2012 05:02 PM
bp-d37c06e3-c97a-4b7b-a99a-344b32120627   06/26/2012 05:01 PM
bp-d42bb5f2-1599-48c9-87a1-5e1d72120627   06/26/2012 05:01 PM
bp-bc286cff-d678-43e5-a0a4-3e7232120626   06/26/2012 04:50 PM

I doubt that the crash has anything to do with the GeForce driver.  I'm running GNOME, not KDE, and virtually all of the crashes occur with no window resizing going on.  In fact, a good many crashes happen with no user interaction with the SeaMonkey browser or mail client whatsoever, while the browser is idling with a blank page or on content that contains zero Flash or Java content, e.g., while viewing the about:crashes page and crash reports.

Surprisingly, I was now able to get Firefox to run long enough to retrieve the crash IDs, while during the day I couldn't get Firefox to even launch and run stably for more than a few seconds.  I've noticed with SeaMonkey and Firefox that there seems to be a dependency on time-of-day whether it will run stably or not.  If the browser is started up between about 9:30 p.m. and 10:00 a.m., it is likely to run around the clock for days without failure.  If it is started during the daytime between 10:00 a.m. and 9:30 p.m., it is likely to crash repeatedly within seconds or minutes after restart.  (Only Mozilla programs exhibit this behavior my system.  If it had anything to do with the GeForce driver, I'd expect to see it crash most, if not all other programs, which it doesn't.)  I've observed this time-of-day crash dependency in SeaMonkey 2.x for 8-9 months now through several revisions, which leads me to suspect that a global time variable is inadvertently being reused for another purpose in the Linux version of the program, leading to this bizarre, random crashing.  How to find it in the source code, though?

Comment 10

[Phoenix]

(In reply to Andrew Poth from comment #9)
> Here are some recent Firefox crash IDs.  They're in sequence and
> all for libpthread-2.11.1.so --
Okay, it really looks like core bug, moving to appropriate section

> If it is started during the daytime between 10:00 a.m. and 9:30 p.m., it is
> likely to crash repeatedly within seconds or minutes after restart.
Hm, just out of curiosity, when you last check your cpu cooling system? Also, is all capacitors on motherboard looks fine (not as on this picture - http://en.wikipedia.org/wiki/File:Defekte_Kondensatoren.jpg)?

Comment 11

[Andrew Poth]

(In reply to Phoenix from comment #10)
> Hm, just out of curiosity, when you last check your cpu cooling system?
> Also, is all capacitors on motherboard looks fine (not as on this picture -
> http://en.wikipedia.org/wiki/File:Defekte_Kondensatoren.jpg)?

Cooling system is OK:  The BIOS setup screen allows me to see the CPU temperature, and it's within the nominal range. I've never seen an over-temperature alarm or shutdown.  Room temperature is generally in the range of 65F-75F, i.e., shirtsleeve environment. BIOS setup screen reports CPU and other supply voltages nominal. No popped electrolytic capacitors on the motherboard as far as I've been able to determine; most of the bad electrolytic capacitor issues were flushed out of the supply chain several years before my motherboard was built.  System passes MEMTEST 86+, so RAM is apparently good.  If there were hardware problems, I'd expect it to affect ALL programs in a similar manner, including the operating system.

Comment 12

[Phoenix]

Do you still see this problem?

Comment 13

[Andrew Poth]

Re: Do you still see this problem?

No.  I now believe it was a hardware problem.  The Shuttle XPC machine I was using last year failed and I switched to a newer IBM ThinkCentre for my Linux box.  A close inspection of the old Shuttle XPC motherboard revealed that the manufacturer used a cheap brand of electrolytic capacitors in the power supply distribution, and although the capacitors looked fine, they had probably gradually dried out and lost performance.  The heavy memory usage of the browser made it draw more peak current than other applications, so the hangs were seen only in the browser until the motherboard deteriorated to the point that other programs also started hanging and the machine even had difficulty booting.  Just before I retired the Shuttle XPC, it was no longer running MEMTEST 86+ successfully.  Since switching to the IBM ThinkCentre, I've seen SeaMonkey hang occasionally, but never again for SIGSEGV in libpthread-2.11.1.so.  It's interesting to note that SeaMonkey was giving a warning of the imminent motherboard failure many months before any diagnostic programs detected it.

If I was the only person reporting this issue, I recommend that it be closed as "resolved".

Comment 14

[Phoenix]

So, I was right about capacitors :)