Closed Bug 227168 Opened 21 years ago Closed 13 years ago

busywaiting on futex; browser hung

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: waider, Unassigned)

Details

(Keywords: hang) 

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016

Unfortunately, I can't provide an exact recipe to duplicate this, but it happens
often enough to be severely annoying. The browser hangs - usually when closing a
window - and strace on the process reveals a tight loop doing this:

gettimeofday({1070276566, 674644}, NULL) = 0
gettimeofday({1070276566, 675495}, NULL) = 0
futex(0x809070c, FUTEX_WAIT, 19849, {0, 149000}) = -1 ETIMEDOUT (Connection
timed out)
read(6, 0xbfffcf0f, 1)                  = -1 EAGAIN (Resource temporarily
unavailable)
gettimeofday({1070276566, 694101}, NULL) = 0
gettimeofday({1070276566, 694939}, NULL) = 0
futex(0x809070c, FUTEX_WAIT, 19850, {0, 162000}) = -1 ETIMEDOUT (Connection
timed out)
read(6, 0xbfffcf0f, 1)                  = -1 EAGAIN (Resource temporarily
unavailable)
gettimeofday({1070276566, 714198}, NULL) = 0
gettimeofday({1070276566, 715062}, NULL) = 0
futex(0x809070c, FUTEX_WAIT, 19851, {0, 136000}) = -1 ETIMEDOUT (Connection
timed out)
read(6, 0xbfffcf0f, 1)                  = -1 EAGAIN (Resource temporarily
unavailable)
gettimeofday({1070276566, 734177}, NULL) = 0
gettimeofday({1070276566, 735030}, NULL) = 0

Also unfortunately I didn't think to check what fd 6 was connected to before
killing the process, so the next time it happens I'll check that. At the time I
had a single browser window with 4 loaded tabs (i.e. it wasn't in the midst of
loading them) and a mail window connected to an IMAP/SSL account. The hang
happened when I tried to close the mail window. Mail is set to expunge Trash on
exit.

Reproducible: Always

Steps to Reproduce:
Not sure. It happens me at least once every browsing session. In some cases, it
happens when I close the browser; all visible windows disappear, but a
mozilla-bin process is still running with the above loop.
Actual Results:  
Browser unusable. It's completely locked out. It doesn't even repaint the screen.

Expected Results:  
At the very least, I should be able to interact with the browser. Obviously, the
loop shouldn't happen in the first place.

[root@qaz root]# rpm -qi mozilla
Name        : mozilla                      Relocations: /usr 
Version     : 1.5                               Vendor: Red Hat, Inc.
Release     : 1                             Build Date: Fri 17 Oct 2003 04:27:12 IST
Install Date: Wed 19 Nov 2003 22:44:44 GMT      Build Host: daffy.perf.redhat.com
Group       : Applications/Internet         Source RPM: mozilla-1.5-1.src.rpm
Size        : 28098447                         License: MPL/NPL/GPL/LGPL
Signature   : (none)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Summary     : A Web browser.
Description :
Mozilla is an open-source Web browser, designed for standards
compliance, performance, and portability.
Keywords: hang
Product: Browser → Seamonkey
Hmmm I have recently been having this similar problem with Firefox 1.0
(Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050202 Firefox/1.0
(Debian package 1.0+dfsg.1-4))

The strace I get shows firefox goes into some sort of loop:

gettimeofday({1109417140, 100237}, NULL) = 0
gettimeofday({1109417140, 100281}, NULL) = 0
gettimeofday({1109417140, 101961}, NULL) = 0
futex(0x8eb489c, FUTEX_WAIT, 18, NULL)  = 0
futex(0x8eb48cc, FUTEX_WAKE, 1)         = 0
gettimeofday({1109417141, 981074}, NULL) = 0
gettimeofday({1109417141, 981188}, NULL) = 0
gettimeofday({1109417141, 981286}, NULL) = 0
futex(0x8eb489c, FUTEX_WAIT, 19, NULL)  = 0
futex(0x8eb48cc, FUTEX_WAKE, 1)         = 0
gettimeofday({1109417142, 61095}, NULL) = 0
gettimeofday({1109417142, 61211}, NULL) = 0
gettimeofday({1109417142, 61307}, NULL) = 0
futex(0x8eb489c, FUTEX_WAIT, 20, NULL)  = 0
futex(0x8eb48cc, FUTEX_WAKE, 1)         = 0
gettimeofday({1109417142, 255026}, NULL) = 0
futex(0x8eb489c, FUTEX_WAIT, 21, NULL)  = 0
futex(0x8eb48cc, FUTEX_WAKE, 1)         = 0
gettimeofday({1109417143, 906057}, NULL) = 0
futex(0x8eb489c, FUTEX_WAIT, 22, NULL)  = 0
futex(0x8eb48cc, FUTEX_WAKE, 1)         = 0

etc...

At first I thought it was related to this bug reported here:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103009

But as no other applications including Mozilla 1.73 (Mozilla/5.0 (X11; U; Linux
i686; en-US; rv:1.7.3) Gecko/20041007 Debian/1.7.3-5) seem affected I am
starting to wonder.

I have no idea why this ought to occur just now and can confirm it is highly
irritating and contiunues to be a problem for each sucessive new window that is
opened under Firefox, however opening Tabs does not seem to be affected at all.

Can we establish if this is an old problem or a renewed one at all?
(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016
> Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016
> 
> Unfortunately, I can't provide an exact recipe to duplicate this, but it happens
> often enough to be severely annoying. The browser hangs - usually when closing a
> window - and strace on the process reveals a tight loop doing this:
> 
> gettimeofday({1070276566, 674644}, NULL) = 0
> gettimeofday({1070276566, 675495}, NULL) = 0
> futex(0x809070c, FUTEX_WAIT, 19849, {0, 149000}) = -1 ETIMEDOUT (Connection
> timed out)
> read(6, 0xbfffcf0f, 1)                  = -1 EAGAIN (Resource temporarily
> unavailable)
> gettimeofday({1070276566, 694101}, NULL) = 0
> gettimeofday({1070276566, 694939}, NULL) = 0
> futex(0x809070c, FUTEX_WAIT, 19850, {0, 162000}) = -1 ETIMEDOUT (Connection
> timed out)
> read(6, 0xbfffcf0f, 1)                  = -1 EAGAIN (Resource temporarily
> unavailable)
> gettimeofday({1070276566, 714198}, NULL) = 0
> gettimeofday({1070276566, 715062}, NULL) = 0
> futex(0x809070c, FUTEX_WAIT, 19851, {0, 136000}) = -1 ETIMEDOUT (Connection
> timed out)
> read(6, 0xbfffcf0f, 1)                  = -1 EAGAIN (Resource temporarily
> unavailable)
> gettimeofday({1070276566, 734177}, NULL) = 0
> gettimeofday({1070276566, 735030}, NULL) = 0
> 
> Also unfortunately I didn't think to check what fd 6 was connected to before
> killing the process, so the next time it happens I'll check that. At the time I
> had a single browser window with 4 loaded tabs (i.e. it wasn't in the midst of
> loading them) and a mail window connected to an IMAP/SSL account. The hang
> happened when I tried to close the mail window. Mail is set to expunge Trash on
> exit.
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> Not sure. It happens me at least once every browsing session. In some cases, it
> happens when I close the browser; all visible windows disappear, but a
> mozilla-bin process is still running with the above loop.
> Actual Results:  
> Browser unusable. It's completely locked out. It doesn't even repaint the screen.
> 
> Expected Results:  
> At the very least, I should be able to interact with the browser. Obviously, the
> loop shouldn't happen in the first place.
> 
> [root@qaz root]# rpm -qi mozilla
> Name        : mozilla                      Relocations: /usr 
> Version     : 1.5                               Vendor: Red Hat, Inc.
> Release     : 1                             Build Date: Fri 17 Oct 2003
04:27:12 IST
> Install Date: Wed 19 Nov 2003 22:44:44 GMT      Build Host: daffy.perf.redhat.com
> Group       : Applications/Internet         Source RPM: mozilla-1.5-1.src.rpm
> Size        : 28098447                         License: MPL/NPL/GPL/LGPL
> Signature   : (none)
> Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
> Summary     : A Web browser.
> Description :
> Mozilla is an open-source Web browser, designed for standards
> compliance, performance, and portability.


I can confirm this problem.  I have seen it for the last few versions 0.9.x
1.0.0 1.0.1 and 1.0.2 (all Fedora Core 1, 3 and now 4 Test 1 + sync to rawhide).

At random intervals, when pulling down a new page, the browser hangs for periods
of up to 20 seconds.  This gives me _plenty_ time to find the pid of firefox
and see what it's doing:

[root@bose ian]# strace -p 3631
Process 3631 attached - interrupt to quit
futex(0x993b560, FUTEX_WAIT, 1, NULL <unfinished ...>

This is with an NFS mounted home directory, BTW. I did try moving ~/.mozilla
to my local disk, but didn't change anything.

strace is (in general) not very useful.  Please use gdb to get a stacktrace,
preferably with a build that doesn't have stripped symbols.
Keywords: stackwanted
I'm having the same problem with Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.7.6) Gecko/20050406 Firefox/1.0.2 (Debian package 1.0.2-3)

(gdb) thread apply all bt

Thread 5 (Thread 1095166896 (LWP 8718)):
#0  0xffffe410 in __kernel_vsyscall ()
#1  0x40ad2c5d in poll () from /lib/tls/i686/cmov/libc.so.6
#2  0x401819a9 in PR_OpenDir () from /usr/lib/mozilla-firefox/libnspr4.so
#3  0x083d6e74 in nsSocketTransportService::Poll ()
#4  0x083d73d6 in nsSocketTransportService::ServiceEventQ ()
#5  0x4011c6fb in nsThread::Main () from /usr/lib/mozilla-firefox/libxpcom.so
#6  0x40182fe9 in PR_Select () from /usr/lib/mozilla-firefox/libnspr4.so
#7  0x401b4ca3 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#8  0x40adb9ba in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 4 (Thread 1117494192 (LWP 8720)):
#0  0xffffe410 in __kernel_vsyscall ()
#1  0x401b75da in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2  0x4017d664 in PR_Unlock () from /usr/lib/mozilla-firefox/libnspr4.so
#3  0x4017d85e in PR_WaitCondVar () from /usr/lib/mozilla-firefox/libnspr4.so
#4  0x4011f16b in TimerThread::UpdateFilter ()
   from /usr/lib/mozilla-firefox/libxpcom.so
#5  0x4011c6fb in nsThread::Main () from /usr/lib/mozilla-firefox/libxpcom.so
#6  0x40182fe9 in PR_Select () from /usr/lib/mozilla-firefox/libnspr4.so
#7  0x401b4ca3 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#8  0x40adb9ba in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 3 (Thread 1134418864 (LWP 13394)):
#0  0xffffe410 in __kernel_vsyscall ()
#1  0x401b75da in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2  0x4017d664 in PR_Unlock () from /usr/lib/mozilla-firefox/libnspr4.so
#3  0x4017d85e in PR_WaitCondVar () from /usr/lib/mozilla-firefox/libnspr4.so
#4  0x083c04e9 in nsIOThreadPool::ThreadFunc ()
#5  0x40182fe9 in PR_Select () from /usr/lib/mozilla-firefox/libnspr4.so
#6  0x401b4ca3 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#7  0x40adb9ba in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 1 (Thread 1086773248 (LWP 8701)):
#0  0xffffe410 in __kernel_vsyscall ()
#1  0x401b741e in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2  0x4017d8df in PR_WaitCondVar () from /usr/lib/mozilla-firefox/libnspr4.so
#3  0x4017dc27 in PR_Wait () from /usr/lib/mozilla-firefox/libnspr4.so
#4  0x401193b2 in PL_WaitForEvent () from /usr/lib/mozilla-firefox/libxpcom.so
#5  0x4011b049 in nsEventQueueImpl::NotifyObservers ()
   from /usr/lib/mozilla-firefox/libxpcom.so
#6  0x083d8e5c in nsSyncStreamListener::WaitForData ()
#7  0x083d91c8 in nsSyncStreamListener::WaitForData ()
#8  0x0840cddf in NS_ImplementChannelOpen ()
#9  0x0847abbc in RDFXMLDataSourceImpl::BlockingParse ()
#10 0x0847b9be in RDFXMLDataSourceImpl::rdfXMLFlush ()
#11 0x08479d1a in RDFServiceImpl::GetDataSource ()
#12 0x08479878 in RDFServiceImpl::GetRDFService ()
#13 0x401345e5 in XPTC_InvokeByIndex ()
   from /usr/lib/mozilla-firefox/libxpcom.so
#14 0x083718fe in XPCWrappedNative::CallMethod ()
#15 0x08377f71 in XPC_WN_CallMethod ()
#16 0x40052526 in js_Invoke () from /usr/lib/mozilla-firefox/libmozjs.so
#17 0x4005c5a9 in js_Interpret () from /usr/lib/mozilla-firefox/libmozjs.so
#18 0x40052bfc in js_Execute () from /usr/lib/mozilla-firefox/libmozjs.so
#19 0x4002dd14 in JS_EvaluateUCScriptForPrincipals ()
   from /usr/lib/mozilla-firefox/libmozjs.so
#20 0x088bcba2 in nsJSContext::EvaluateString ()
#21 0x08763165 in GlobalWindowImpl::RunTimeout ()
#22 0x08763882 in GlobalWindowImpl::TimerCallback ()
---Type <return> to continue, or q <return> to quit---
#23 0x4011d8a6 in nsTimerImpl::Fire ()
   from /usr/lib/mozilla-firefox/libxpcom.so
#24 0x4011d914 in handleTimerEvent () from /usr/lib/mozilla-firefox/libxpcom.so
#25 0x40119237 in PL_HandleEvent () from /usr/lib/mozilla-firefox/libxpcom.so
#26 0x40119164 in PL_ProcessPendingEvents ()
   from /usr/lib/mozilla-firefox/libxpcom.so
#27 0x4011adf9 in nsEventQueueImpl::NotifyObservers ()
   from /usr/lib/mozilla-firefox/libxpcom.so
#28 0x08568135 in nsBaseWidget::FreeNativeData ()
#29 0x40622dbf in g_vasprintf () from /usr/lib/libglib-2.0.so.0
#30 0x405fd582 in g_main_depth () from /usr/lib/libglib-2.0.so.0
#31 0x405fe5f8 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#32 0x405fe930 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#33 0x405feed3 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#34 0x402e3c13 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#35 0x08568478 in nsAppShell::ReleaseGlobals ()
#36 0x08a0e0b4 in nsAppShellService::AttemptingQuit ()
#37 0x08c12e20 in xre_main ()
#38 0x0834afa4 in main ()
Also broken in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050421
Firefox/1.0.3 (Debian package 1.0.3-2)
I got the same problem with firefox 1.0.1, 1.0.2 and 1.0.4. strace showed that
firefox got frozen at the futex call. It happen alot when my connection unstable
(or slow). Really annoying.
Hi,

I also have that problem with my firefox (directory local, _not_ NFS mounted).

And I also have this problem with Thunderbird when accessing LDAP directories.
Thunderbird falls to sleep for about 20 seconds, not even the windows are displayed.




I also want to comment that this weird thing occurs only on systems with glibc
supporting NTPL (dynamically linked with libs in /lib/tls/). My kernel is 2.6.x,
I never test this issue on 2.4 series. Most known workaround is to export to env
LD_ASSUME_KERNEL=2.4.1 (for example, it can be 2.4.x - x is non-zero value) and
running firefox (LD_ASSUME_KERNEL=2.4.1 firefox &), but often this doesn't work
- firefox is still hangs. This bug was reported as
https://bugzilla.mozilla.org/show_bug.cgi?id=281798

This is present in Deer Park Alpha2, too.
Would anyone please care about this problem?

It sometimes renders firefox effectively unusable.

regards
Hadmut

dumping in networking
Assignee: general → darin
Component: General → Networking
Keywords: stackwanted
Product: Mozilla Application Suite → Core
QA Contact: general → benc
Hi,

I found (at least in the few cases where I was dumping the network while the browser hangs) that (at least) one reason for the problem is the automatic RSS download. 

The RSS download procedures are _really_ annoying. They can make web pages inaccessible (e.g. https pages which require client certs) and cause these browser hangs. 

PLEASE stop that automatic RSS loading and update an RSS link only if 
- it has expired
- it is accessed


regards
Hadmut

See also Bug 316005
Assignee: darin → nobody
QA Contact: benc → networking
Is this still an issue ?
I am still experiencing a problem with Firefox on Linux. I'm currently running 3.0.6 on a 32-bit CentOS 5.2 system (fully updated). I have the FoxyProxy, VMWare Console, BetterGmail, Flash and AdBlocker plugins installed (but it occurs even with all the plugins disabled). I can't pinpoint exactly when it starts to slow down, but running an strace shows the following:

poll([{fd=10, events=POLLIN}, {fd=3, events=POLLIN}, {fd=16, events=POLLIN|POLLPRI}, {fd=19, events=POLLIN|POLLPRI}, {fd=20, events=POLLIN|POLLPRI}, {fd=21, events=POLLIN|POLLPRI}, {fd=30, events=POLLIN}, {fd=18, events=POLLIN|POLLPRI}, {fd=31, events=POLLIN}], 9, 0) = 0
gettimeofday({1236431942, 991872}, NULL) = 0
gettimeofday({1236431942, 991968}, NULL) = 0
gettimeofday({1236431942, 992024}, NULL) = 0
gettimeofday({1236431942, 992084}, NULL) = 0
gettimeofday({1236431942, 992153}, NULL) = 0
gettimeofday({1236431942, 992211}, NULL) = 0
gettimeofday({1236431942, 992266}, NULL) = 0
gettimeofday({1236431942, 992334}, NULL) = 0
gettimeofday({1236431942, 992396}, NULL) = 0
ioctl(3, FIONREAD, [0])                 = 0
gettimeofday({1236431942, 992517}, NULL) = 0
poll( <unfinished ...>

This continues constantly. Even if nothing else is happening in the browser, CPU is pegged at 100%.  

Problem seems to occur no matter how many tabs are open (though *seems* worse with more tabs).
I just experienced this again, this time it was when the browser was about to open a pdf-file. Running firefox 3.0.12 on a 64-bit debian system. Backtrace from gdb:

#0  0x00007f45cf2d3c09 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#1  0x00007f45cf508eb4 in PR_WaitCondVar () from /usr/lib/libnspr4.so.0d
#2  0x00007f45cf5104e0 in ?? () from /usr/lib/libnspr4.so.0d
#3  0x00007f45d33fb92f in nsProcess::Run (this=0x6c059b0, blocking=1, args=0x7fff31d8c8c0, count=<value optimized out>, 
    pid=<value optimized out>) at nsProcessCommon.cpp:374
#4  0x00007f45d31ecfbd in nsOSHelperAppService::GetHandlerAndDescriptionFromMailcapFile (aFilename=<value optimized out>, 
    aMajorType=@0x7fff31d8d4f0, aMinorType=@0x7fff31d8d4e0, aTypeOptions=@0x7fff31d8d3d0, aHandler=@0x7fff31d8cef0, 
    aDescription=@0x7fff31d8cf90, aMozillaFlags=@0x7fff31d8ce50) at ./unix/nsOSHelperAppService.cpp:1160
#5  0x00007f45d31ed380 in nsOSHelperAppService::DoLookUpHandlerAndDescription (aMajorType=@0x7fff31d8d4f0, 
    aMinorType=@0x7fff31d8d4e0, aTypeOptions=@0x7fff31d8d3d0, aHandler=@0x7fff31d8cef0, aDescription=@0x7fff31d8cf90, 
    aMozillaFlags=@0x7fff31d8ce50, aUserData=1) at ./unix/nsOSHelperAppService.cpp:979
#6  0x00007f45d31ed580 in nsOSHelperAppService::GetFromType (this=0x22febe0, aMIMEType=@0x7fff31d8d560)
    at ./unix/nsOSHelperAppService.cpp:1500
#7  0x00007f45d31ee2d2 in nsOSHelperAppService::GetMIMEInfoFromOS (this=0x22febe0, aType=@0x7fff31d8d690, aFileExt=@0x7fff31d8db20, 
    aFound=0x7fff31d8d72c) at ./unix/nsOSHelperAppService.cpp:1619
#8  0x00007f45d31e32fb in nsExternalHelperAppService::GetFromTypeAndExtension (this=0x22febe0, aMIMEType=@0x8de1040, 
    aFileExt=@0x7fff31d8db20, _retval=0x7fff31d8dc20) at nsExternalHelperAppService.cpp:2361
#9  0x00007f45d31e7318 in nsExternalHelperAppService::DoContent (this=<value optimized out>, aMimeContentType=@0x8de1040, 
    aRequest=<value optimized out>, aWindowContext=0x381a9c0, aForceSave=0, aStreamListener=0x8de1028)
    at nsExternalHelperAppService.cpp:626
#10 0x00007f45d31df8cd in nsDocumentOpenInfo::DispatchContent (this=0x8de1010, request=0x6032568, aCtxt=<value optimized out>)
    at nsURILoader.cpp:601
#11 0x00007f45d31dfe73 in nsDocumentOpenInfo::OnStartRequest (this=0x8de1010, request=0x6032568, aCtxt=0x0) at nsURILoader.cpp:280
#12 0x00007f45d2d64fd8 in nsHttpChannel::CallOnStartRequest (this=0x6032520) at nsHttpChannel.cpp:761
#13 0x00007f45d2d651c4 in nsHttpChannel::ProcessNormal (this=0x6032520) at nsHttpChannel.cpp:1013
#14 0x00007f45d2d03950 in nsInputStreamPump::OnStateStart (this=0x98065a0) at nsInputStreamPump.cpp:439
#15 0x00007f45d2d03c1c in nsInputStreamPump::OnInputStreamReady (this=0x98065a0, stream=0x80) at nsInputStreamPump.cpp:395
#16 0x00007f45d33e7cf2 in nsInputStreamReadyEvent::Run (this=0x8230100) at nsStreamUtils.cpp:111
#17 0x00007f45d33f9e26 in nsThread::ProcessNextEvent (this=0x1da3490, mayWait=1, result=0x7fff31d8e1ac) at nsThread.cpp:510
#18 0x00007f45d33cfe4a in NS_ProcessNextEvent_P (thread=0x4bf9b9c, mayWait=1) at nsThreadUtils.cpp:230
#19 0x00007f45d3354579 in nsBaseAppShell::Run (this=0x1db2470) at nsBaseAppShell.cpp:170
#20 0x00007f45d3236bfd in nsAppStartup::Run (this=0x25f89b0) at nsAppStartup.cpp:181
#21 0x00007f45d2cbedd4 in XRE_main (argc=<value optimized out>, argv=<value optimized out>, aAppData=<value optimized out>)
    at nsAppRunner.cpp:3208
#22 0x00000000004014cb in main (argc=5, argv=0x7fff31d8f7a8) at nsXULStub.cpp:421
mj writes I don't know if this is gone "I've been stopped using Linux as primary desktop, and my Linux box seems not to use TLS now (Slackware 12.2). Firefox 3.0.10 is stable in that environment."
It has been quite a while without this happening, but today it happened again, this time I was using 3.6.4 on a debian 64-bit system. Backtrace from gdb:
(gdb) bt
#0  0x00007f6335623f89 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#1  0x00007f63305fcada in PR_WaitCondVar (cvar=0x7f630bcd56c0, timeout=4294967295) at ptsynch.c:417
#2  0x00007f6330603d00 in _MD_WaitUnixProcess (process=0x7f630d83f8f4, exitCode=0x7fff03db203c) at uxproces.c:853
#3  0x00007f63344b3aa9 in nsProcess::Monitor (arg=<value optimized out>) at nsProcessCommon.cpp:263
#4  0x00007f63344b3ca9 in nsProcess::RunProcess (this=0x7f630bc2d190, blocking=1, args=0x7fff03db25a0, count=<value optimized out>, 
    observer=<value optimized out>, holdWeak=<value optimized out>) at nsProcessCommon.cpp:440
#5  0x00007f633422a01f in nsOSHelperAppService::GetHandlerAndDescriptionFromMailcapFile (aFilename=<value optimized out>, 
    aMajorType=<value optimized out>, aMinorType=<value optimized out>, aTypeOptions=<value optimized out>, 
    aHandler=<value optimized out>, aDescription=<value optimized out>, aMozillaFlags=...) at ./unix/nsOSHelperAppService.cpp:1159
#6  0x00007f633422a414 in nsOSHelperAppService::DoLookUpHandlerAndDescription (aMajorType=..., aMinorType=..., 
    aTypeOptions=<value optimized out>, aHandler=<value optimized out>, aDescription=..., aMozillaFlags=..., aUserData=1)
    at ./unix/nsOSHelperAppService.cpp:979
#7  0x00007f633422a5e6 in nsOSHelperAppService::GetFromType (this=0x7f63206a8400, aMIMEType=...)
    at ./unix/nsOSHelperAppService.cpp:1433
#8  0x00007f633422b23c in nsOSHelperAppService::GetMIMEInfoFromOS (this=0x7f63206a8400, aType=..., aFileExt=..., 
    aFound=0x7fff03db338c) at ./unix/nsOSHelperAppService.cpp:1552
#9  0x00007f63342209df in nsExternalHelperAppService::GetFromTypeAndExtension (this=0x7f63206a8400, aMIMEType=<value optimized out>, 
    aFileExt=..., _retval=0x7fff03db3880) at nsExternalHelperAppService.cpp:2463
#10 0x00007f6334223ddb in nsExternalHelperAppService::DoContent (this=<value optimized out>, aMimeContentType=<value optimized out>, 
    aRequest=<value optimized out>, aWindowContext=<value optimized out>, aForceSave=<value optimized out>, 
    aStreamListener=0x7f631b0d8a78) at nsExternalHelperAppService.cpp:706
#11 0x00007f633421cf22 in nsDocumentOpenInfo::DispatchContent (this=0x7f631b0d8a60, request=0x7f631b038448, 
    aCtxt=<value optimized out>) at nsURILoader.cpp:594
#12 0x00007f633421d102 in nsDocumentOpenInfo::OnStartRequest (this=0x7f631b0d8a60, request=0x7f631b038448, aCtxt=0x0)
    at nsURILoader.cpp:280
#13 0x00007f6333cbb5af in nsHttpChannel::CallOnStartRequest (this=0x7f631b038400) at nsHttpChannel.cpp:849
#14 0x00007f6333cbe128 in nsHttpChannel::ProcessNormal (this=0x7f631b038400) at nsHttpChannel.cpp:1155
#15 0x00007f6333cbf3f9 in nsHttpChannel::ProcessResponse (this=0x7f631b038400) at nsHttpChannel.cpp:1080
#16 0x00007f6333cbf52d in nsHttpChannel::OnStartRequest (this=0x7f631b038400, request=0x7f63135455c0, ctxt=<value optimized out>)
    at nsHttpChannel.cpp:5187
#17 0x00007f6333c58354 in nsInputStreamPump::OnStateStart (this=0x7f63135455c0) at nsInputStreamPump.cpp:439
#18 0x00007f6333c58715 in nsInputStreamPump::OnInputStreamReady (this=0x7f63135455c0, stream=0x80) at nsInputStreamPump.cpp:395
#19 0x00007f633449ee7a in nsInputStreamReadyEvent::Run (this=0x7f6314067a30) at nsStreamUtils.cpp:112
#20 0x00007f63344b1d23 in nsThread::ProcessNextEvent (this=0x7f6334d2daf0, mayWait=1, result=0x7fff03db3e8c) at nsThread.cpp:527
#21 0x00007f63344864f1 in NS_ProcessNextEvent_P (thread=0x7f630bcd56cc, mayWait=128) at nsThreadUtils.cpp:250
#22 0x00007f633441b9a4 in mozilla::ipc::MessagePump::Run (this=0x7f6328442b00, aDelegate=0x7f6334d3e060) at MessagePump.cpp:142
#23 0x00007f633445c4d4 in MessageLoop::RunHandler (this=0x7f630bcd56cc) at ./src/base/message_loop.cc:199
#24 MessageLoop::Run (this=0x7f630bcd56cc) at ./src/base/message_loop.cc:173
#25 0x00007f6334398c25 in nsBaseAppShell::Run (this=0x7f6323e94880) at nsBaseAppShell.cpp:174
#26 0x00007f6334272a26 in nsAppStartup::Run (this=0x7f6323efe140) at nsAppStartup.cpp:183
#27 0x00007f6333be23f4 in XRE_main (argc=<value optimized out>, argv=<value optimized out>, aAppData=<value optimized out>)
    at nsAppRunner.cpp:3493
#28 0x00000000004025b5 in main (argc=4, argv=0x7fff03db9fc8) at nsXULStub.cpp:595
Related with bug 570315 ? (in SeaMonkey: sporadic hangs, usually zero CPU, rarely high CPU, no response to keyboard & mouse, no screen repaint, ps says that WCHAN is futex_wait_queue_me, Breakpad comes up if I do kill -ILL or kill -SEGV on the SeaMonkey process)
oops, I meant bug 570316
(In reply to comment #19 / #20)
> Related with bug 570316 ?  
(which got fixed by Bug 637286 - Firefox4 freeze and is unusable when I try to open add-ons tab with Extensions pane selected)

I'd think not. I don't see any significant similarity in stacks (OTOH some of them are skimpy)

Closing this bug seems appropriate, because it is highly doubtful the OP and reports prior to 2009 are related to anything recent.  Therefore, I suggest we close this bug and anyone seeing a problem using version 4 start a new bug with a stacktrace and post the new bug# here.  Any objections?
You need to log in before you can comment on or make changes to this bug.