bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

Crash in JS GC while Mozilla is in background



18 years ago
14 years ago


(Reporter: Bill Law, Assigned: asa)



Windows NT

Firefox Tracking Flags

(Not tracked)




18 years ago
I was composing a mail message using Communicator (forgive me) and Mozilla just 
up and died (I hadn't interacted with it for a few minutes).  I know this is 
totally unreproducible but a pattern of bug reports like this might lead to us 
finding the cause.

All I had donw was type in the name of a .exe file in order to get the "unknown 
content type handler" dialog displayed.  So I had about:blank in a Nav window, 
plus that dialog open, nothing else was going on.

Here's the stack trace:

NTDLL! 77f76148()
gc_root_marker(JSHashEntry * 0x07485d30, int 0x0000001f, void * 0x00e81d40) line 
785 + 35 bytes
JS_HashTableEnumerateEntries(JSHashTable * 0x00d04b20, int (JSHashEntry *, int, 
void *)* 0x002aff60 gc_root_marker(JSHashEntry *, int, void *), void * 
0x00e81d40) line 364 + 15 bytes
js_GC(JSContext * 0x03012e90) line 952 + 21 bytes
js_ForceGC(JSContext * 0x03012e90) line 810 + 9 bytes
JS_GC(JSContext * 0x03012e90) line 1165 + 9 bytes
nsJSContext::GC(nsJSContext * const 0x03017d50) line 1126 + 13 bytes
GlobalWindowImpl::SetNewDocument(GlobalWindowImpl * const 0x030154b0, 
nsIDOMDocument * 0x00000000) line 289
DocumentViewerImpl::~DocumentViewerImpl() line 410
DocumentViewerImpl::`scalar deleting destructor'(unsigned int 0x00000001) + 15 
DocumentViewerImpl::Release(DocumentViewerImpl * const 0x07434450) line 348 + 
154 bytes
nsCOMPtr<nsIContentViewer>::assign_assuming_AddRef(nsIContentViewer * 
0x00000000) line 472
nsCOMPtr<nsIContentViewer>::assign_with_AddRef(nsISupports * 0x00000000) line 
nsCOMPtr<nsIContentViewer>::operator=(nsIContentViewer * 0x00000000) line 584
nsDocShell::SetupNewViewer(nsDocShell * const 0x030257b0, nsIContentViewer * 
0x0628cd90) line 2282
nsWebShell::SetupNewViewer(nsWebShell * const 0x030257b0, nsIContentViewer * 
0x0628cd90) line 560 + 13 bytes
nsDocShell::CreateContentViewer(nsDocShell * const 0x030257b0, const char * 
0x0012f904, nsIChannel * 0x062b50b0, nsIStreamListener * * 0x0012f958) line 2171 
+ 24 bytes
nsDSURIContentListener::DoContent(nsDSURIContentListener * const 0x03025490, 
const char * 0x0012f904, int 0x00000000, const char * 0x1009ebe0 
gCommonEmptyBuffer, nsIChannel * 0x062b50b0, nsIStreamListener * * 0x0012f958, 
int * 0x0012f8e8) line 100 + 33 bytes
nsDocumentOpenInfo::DispatchContent(nsIChannel * 0x062b50b0, nsISupports * 
0x00000000) line 357 + 109 bytes
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x062b26c0, 
nsIChannel * 0x062b50b0, nsISupports * 0x00000000) line 231 + 16 bytes
nsHTTPFinalListener::OnStartRequest(nsHTTPFinalListener * const 0x062b4b20, 
nsIChannel * 0x062b50b0, nsISupports * 0x00000000) line 1157
InterceptStreamListener::OnStartRequest(InterceptStreamListener * const 
0x0629e670, nsIChannel * 0x062b50b0, nsISupports * 0x00000000) line 1140
nsHTTPServerListener::FinishedResponseHeaders() line 1082 + 48 bytes
nsHTTPServerListener::OnDataAvailable(nsHTTPServerListener * const 0x0629f160, 
nsIChannel * 0x062a2cd4, nsISupports * 0x062b50b0, nsIInputStream * 0x0629e50c, 
unsigned int 0x00000000, unsigned int 0x00000000) line 427 + 8 bytes
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x06299940) 
line 401 + 47 bytes
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x0629c120) line 97 + 12 bytes
PL_HandleEvent(PLEvent * 0x0629c120) line 575 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x010fce40) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x005403a6, unsigned int 0x0000c0d4, unsigned int 
0x00000000, long 0x010fce40) line 1032 + 9 bytes
USER32! 77e713ed()

Comment 1

18 years ago
Alec, do you think this bug is related to bug 43466? The stack traces 
seem similar to me, but I'm not an expert.  Thanks - Phil

Comment 2

18 years ago
I don't know for certain, but it wouldn't surprise me. The real question is, do 
you remember opening a modal dialog before this happened? If so, then I'd be 
more certain

the real way to tell is to look at (char *)he->value if you crash again, and see 
if it's window_object or not. If it is, then it's the same crash.

Comment 3

18 years ago
I notice this from the original report above: 

"All I had done was type in the name of a .exe file in order to get the "unknown 
content type handler" dialog displayed.  So I had about:blank in a Nav window, 
plus that dialog open, nothing else was going on."

So it looks like there was a modal dialog open at the time of the crash - but it 
was in Communicator, not Mozilla. Is that relevant, do you think ...?

Comment 4

18 years ago
it's not if there's a modal dialog open at the time, it's if a modal dialog has 
ever been opened before (it's actually the /closing/ of a modal dialog that 
triggers the problem)

Comment 5

18 years ago
Adding crash keyword
Keywords: crash

Comment 6

18 years ago
Reassigning to Browser-General; not a JS Engine issue.

I believe that this bug may be a duplicate of bug 43466. 
See Alec's comment above to determine if it is ...
Assignee: rogerl → asa
Component: Javascript Engine → Browser-General
QA Contact: pschwartau → doronr

Comment 7

18 years ago
Another very similar stack trace can be found in bug 41610.

Comment 8

18 years ago
could be a dom 0 issue

Comment 9

18 years ago
Bug moved to http://bugscape.netscape.com/.

If the move succeeded, asa@mozilla.org will recieve a mail
containing the number of the new bug in the other database.
If all went well,  please mark this bug verified, and paste
in a link to the new bug. Otherwise, reopen this bug.
Last Resolved: 18 years ago
Resolution: --- → MOVED

Comment 10

18 years ago
damn! sorry about that.  Re-opening. 
adding danm to cc: list.  Dan, do you think this is the same as bug 43466
Resolution: MOVED → ---

Comment 11

18 years ago
bug 43466 is Resolved FIXED and bug 41610 is WORKSFORME.  law, are you still 
seeing this?

Comment 12

18 years ago
No.  As I said at the outset, this was a totally unreproducible problem (I
reported it just to add a data point if we saw similar crashes with this stack).

Bugs were fixed in this area, so it is most likely the bug is fixed and can be
closed thusly.

Comment 13

18 years ago
thanks law for the followup.
Last Resolved: 18 years ago18 years ago
Resolution: --- → WORKSFORME
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.