Firefox freezes with SIG33 on MSNBC site

RESOLVED INVALID

Status

()

Firefox
General
--
critical
RESOLVED INVALID
12 years ago
12 years ago

People

(Reporter: Brad Jackson, Unassigned)

Tracking

({crash})

1.5.0.x Branch
x86
Linux
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: read comment 2., URL)

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060604 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060604 Firefox/1.5.0.4

This has been happening for 1-2 weeks. Below stack trace is with compiler optimiztions on, so it's possibly inaccurate.

Program received signal SIG33, Real-time event 33.
[Switching to Thread -1280939088 (LWP 3209)]
0xffffe410 in __kernel_vsyscall ()
Current language:  auto; currently c
(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0x4e3a0d2c in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/tls/libpthread.so.0
#2  0xb7e64431 in pt_TimedWait (cv=0x8c45c24, ml=0x8c45bc0, timeout=Variable "timeout" is not available.
)
    at ptsynch.c:280
#3  0xb7e65189 in PR_WaitCondVar (cvar=0x8c45c20, timeout=60000)
    at ptsynch.c:407
#4  0x0818066d in nsHostResolver::GetHostToLookup (this=0x8c45b60, 
    result=0xb3a66428) at nsHostResolver.cpp:556
#5  0x08180a9b in nsHostResolver::ThreadFunc (arg=0x8c45b60)
    at nsHostResolver.cpp:641
#6  0xb7e6b18b in _pt_root (arg=0x95b93d8) at ptthread.c:220
#7  0x4e39ec40 in start_thread () from /lib/tls/libpthread.so.0
#8  0x4e18d0ee in clone () from /lib/tls/libc.so.6


Reproducible: Always

Steps to Reproduce:
1. Go to http://www.msnbc.msn.com/
2. Also possibly seen on other sites such as match.com, but is not reproducible.



Actual Results:  
Firefox freezes and stops responding to input.

Expected Results:  
Page should load normally
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9a1) Gecko/20060606 Minefield/3.0a1 - Build ID: 0000000000
WFM.

Could you build with --enable-debug and get a more complete stack trace using gdb please? Alternatively, you could get an official Mozilla build and provide a Talkback ID. (http://kb.mozillazine.org/Talkback)
Keywords: crash
Version: unspecified → 1.5.0.x Branch

Comment 2

12 years ago
your debugger is being stupid.

handle SIG33 noprint
handle SIG32 noprint
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → INVALID
(Reporter)

Comment 3

12 years ago
There is still a real freezing problem when Firefox is run without a debugger. I've also seen a glibc corrupted double-linked list error or something like that when running a non-debug version under the debugger.

Should I submit a new bug when I figure out how to reproduce it, or should I add more comments here and change this bug's description?
(Reporter)

Comment 4

12 years ago
I finally got it to crash.  It is not reproducible. I had a different type of segmentation fault crash before this that completely froze my X session and I couldn't get a trace from the terminal before I killed the firefox process from another console. I will keep trying to get that type again.

*** glibc detected *** corrupted double-linked list: 0x09cdaeb8 ***

Program received signal SIGABRT, Aborted.
[Switching to Thread -1211017536 (LWP 6893)]
0xffffe410 in __kernel_vsyscall ()
Current language:  auto; currently c
(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0x4e0e8ef1 in raise () from /lib/tls/libc.so.6
#2  0x4e0ea83b in abort () from /lib/tls/libc.so.6
#3  0x4e11eff5 in __fsetlocking () from /lib/tls/libc.so.6
#4  0x4e1256ac in malloc_usable_size () from /lib/tls/libc.so.6
#5  0x4e125a02 in free () from /lib/tls/libc.so.6
#6  0xb7f1f830 in nsStringBuffer::Release (this=0x68) at nsSubstring.cpp:189
#7  0xb7f1fff9 in nsSubstring::Finalize (this=Variable "this" is not available.
) at nsSubstring.cpp:116
#8  0xb7f254be in ~nsAString_internal (this=Variable "this" is not available.
) at nsTAString.cpp:57
#9  0x08495eb6 in ~nsDocument (this=0x9b50d88)
    at ../../../dist/include/string/nsTSubstring.h:56
#10 0x08506327 in ~nsHTMLDocument (this=0x9b50d88) at nsHTMLDocument.cpp:298
#11 0x0848c387 in nsDocument::Release (this=0x9b50d88) at nsDocument.cpp:880
#12 0x080a234b in XPCJSRuntime::GCCallback (cx=0x92593c0, status=JSGC_END)
    at xpcjsruntime.cpp:562
#13 0x08557d86 in DOMGCCallback (cx=0x92593c0, status=JSGC_END)
    at nsJSEnvironment.cpp:2189
#14 0xb7f78a9c in js_GC (cx=0x92593c0, gcflags=0) at jsgc.c:1985
#15 0xb7f78c21 in js_ForceGC (cx=0x92593c0, gcflags=0) at jsgc.c:1522
#16 0xb7f4d528 in JS_GC (cx=0x92593c0) at jsapi.c:1837
#17 0x08557dfa in nsJSContext::Notify (this=0x931a1d8, timer=0x9daadd8)
    at nsJSEnvironment.cpp:2147
#18 0xb7f0381f in nsTimerImpl::Fire (this=0x9daadd8) at nsTimerImpl.cpp:397
---Type <return> to continue, or q <return> to quit---
#19 0xb7f040db in handleTimerEvent (event=0xb3a05ed0) at nsTimerImpl.cpp:459
#20 0xb7eff2b8 in PL_HandleEvent (self=0xb3a05ed0) at plevent.c:688
#21 0xb7eff5f0 in PL_ProcessPendingEvents (self=0x8c643b0) at plevent.c:623
#22 0xb7f0153b in nsEventQueueImpl::ProcessPendingEvents (this=0x8c64368)
    at nsEventQueue.cpp:417
#23 0x082dc93b in event_processor_callback (source=0x9083af8, 
    condition=G_IO_IN, data=0x8c64368) at nsAppShell.cpp:67
#24 0x4e3614c2 in g_vasprintf () from /usr/lib/libglib-2.0.so.0
#25 0x09083af8 in ?? ()
#26 0x00000001 in ?? ()
#27 0x08c64368 in ?? ()
#28 0x4e392180 in ?? () from /usr/lib/libglib-2.0.so.0
#29 0x4e392180 in ?? () from /usr/lib/libglib-2.0.so.0
#30 0x4e3a00b0 in __pthread_mutex_unlock_usercnt ()
   from /lib/tls/libpthread.so.0
#31 0x4e3377cf in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#32 0x00000001 in ?? ()
#33 0x4e392180 in ?? () from /usr/lib/libglib-2.0.so.0
#34 0x08bf49c0 in ?? ()
#35 0x4e33a5bc in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#36 0x00000000 in ?? ()
(Reporter)

Comment 5

12 years ago
Here's a segfault trace. If you need more detail for either of these, I can try a build with optimizations like omit-frame-pointer turned off. It will take me a while because my old machine only has 256 MB of memory, so a build takes hours to finish and eats all free memory and tons of swap to link.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1211189568 (LWP 10018)]
0x4e1259ec in free () from /lib/tls/libc.so.6
Current language:  auto; currently c
(gdb) bt
#0  0x4e1259ec in free () from /lib/tls/libc.so.6
#1  0xb7f93068 in js_FinalizeStringRT (rt=0x8c54448, str=0x190)
    at jsstr.c:2722
#2  0xb7f93096 in js_FinalizeString (cx=0x9233078, str=0x954c4d8)
    at jsstr.c:2704
#3  0xb7f4e67f in js_GC (cx=0x9233078, gcflags=0) at jsgc.c:1869
#4  0xb7f4ec21 in js_ForceGC (cx=0x9233078, gcflags=0) at jsgc.c:1522
#5  0xb7f23528 in JS_GC (cx=0x9233078) at jsapi.c:1837
#6  0x08557dfa in nsJSContext::Notify (this=0x9319cc0, timer=0x9defad8)
    at nsJSEnvironment.cpp:2147
#7  0xb7ed981f in nsTimerImpl::Fire (this=0x9defad8) at nsTimerImpl.cpp:397
#8  0xb7eda0db in handleTimerEvent (event=0xb3a00470) at nsTimerImpl.cpp:459
#9  0xb7ed52b8 in PL_HandleEvent (self=0xb3a00470) at plevent.c:688
#10 0xb7ed55f0 in PL_ProcessPendingEvents (self=0x8c64360) at plevent.c:623
#11 0xb7ed753b in nsEventQueueImpl::ProcessPendingEvents (this=0x8c3ede0)
    at nsEventQueue.cpp:417
#12 0x082dc93b in event_processor_callback (source=0x8f8d888, 
    condition=G_IO_IN, data=0x8c3ede0) at nsAppShell.cpp:67
#13 0x4e3614c2 in g_vasprintf () from /usr/lib/libglib-2.0.so.0
#14 0x08f8d888 in ?? ()
#15 0x00000001 in ?? ()
#16 0x08c3ede0 in ?? ()
---Type <return> to continue, or q <return> to quit---
#17 0x4e392180 in ?? () from /usr/lib/libglib-2.0.so.0
#18 0x4e392180 in ?? () from /usr/lib/libglib-2.0.so.0
#19 0x4e3a00b0 in __pthread_mutex_unlock_usercnt ()
   from /lib/tls/libpthread.so.0
#20 0x4e3377cf in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#21 0x00000001 in ?? ()
#22 0x4e392180 in ?? () from /usr/lib/libglib-2.0.so.0
#23 0x08bf49c0 in ?? ()
#24 0x4e33a5bc in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#25 0x00000000 in ?? ()

Comment 6

12 years ago
well, while both of those are valid crashes and both are js_GC crashes, one's a dom crash, and one's a spidermonkey crash, and your summary is currently for the invalid problem.

you're free to reopen and resummarize to one of the two valid stack implicated problems. however, i'm not sure what more can be done w/o valgrind which would make your 256mb machine really cry. my guess is that the document is a double free of some sort, but i have no idea about the string table.

Comment 7

12 years ago
Created attachment 225922 [details]
GDB output on my machine

I also get these SIG33 crashes on my machine. This is with Firefox I compiled on 20060616 (with debug enabled). I don't know if this output is of any help. If there is no usable info here then I would like to know how to get some more useful info about the prolem.

Comment 8

12 years ago
I forgot to tell what I did to get my Firefox frozen. In one tab I visited bug 335875 and while on this tab I went to Help > About Minefield and then it froze.

Comment 9

12 years ago
(In reply to comment #7)
> I also get these SIG33 crashes on my machine.

please read bugs before commenting. this is covered by comment 2.
Whiteboard: read comment 2.

Comment 10

12 years ago
I did read comment #2 but didn't understand what it means at that time. I later searched it on the internet and I understand now that SIG31, SIG32... signals are just for time synchronization between threads and are not errors. And I also now know that with the "handle SIG33 nostop noprint" you tell gdb to ignore these signals and continue the execution.

So this is the short summary if someone else stumbles upon this. And sorry, timeless, for any troubles.
You need to log in before you can comment on or make changes to this bug.