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 bytes 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 849 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() 010fce40()
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
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.
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 ...?
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)
Adding crash keyword
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
QA Contact: pschwartau → doronr
Another very similar stack trace can be found in bug 41610.
could be a dom 0 issue
Bug moved to http://bugscape.netscape.com/. If the move succeeded, email@example.com 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.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → MOVED
damn! sorry about that. Re-opening. adding danm to cc: list. Dan, do you think this is the same as bug 43466
Status: RESOLVED → REOPENED
Resolution: MOVED → ---
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.
thanks law for the followup.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.