Build: 9/27/99 SeaMonkey build 1. From http://jimbob/trigger2.html, clear the text from the Trigger URL field and enter Webbies:blah.jar (I tried using a real jar file, but it doesn't mattter) RESULT: Crash. TalkBack Incident ID 13981126 Call Stack: (Signature = NSAPPSHELL.DLL + 0x409e (0x60ad409e) 6472f2cc) NSAPPSHELL.DLL + 0x409e (0x60ad409e) NSAPPSHELL.DLL + 0x41fc (0x60ad41fc) NSAPPSHELL.DLL + 0x3ffc (0x60ad3ffc) nsWebShell::OnEndDocumentLoad [d:\builds\seamonkey\mozilla\webshell\src\nsWebShell.cpp, line 3439] nsDocLoaderImpl::FireOnEndDocumentLoad [d:\builds\seamonkey\mozilla\webshell\src\nsDocLoader.cpp, line 889] nsDocLoaderImpl::OnStopRequest [d:\builds\seamonkey\mozilla\webshell\src\nsDocLoader.cpp, line 768] nsLoadGroup::RemoveChannel [d:\builds\seamonkey\mozilla\netwerk\base\src\nsLoadGroup.cpp, line 600] nsFileChannel::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\protocol\file\src\nsFileChannel.cpp, line 475] nsOnStopRequestEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 283] nsStreamListenerEvent::HandlePLEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 153] PL_HandleEvent [plevent.c, line 542] PL_ProcessPendingEvents [plevent.c, line 501] _md_EventReceiverProc [plevent.c, line 974] KERNEL32.DLL + 0x363b (0xbff7363b) KERNEL32.DLL + 0x242e7 (0xbff942e7) 0x00638bea http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=15&cp=1&ck1= SUser+email+address&cd1=%25jimmylee%40netscape%2Ecom%25&co1=like&bbid=13981126 EXPECTED RESULT: Error message in Install.log and possibly even in a dialog. NOTE: Originally, I was investigating this on the Mac, but I found out it crashes similarly for Linux and Windows as well.

unable to reproduce in my build... will try to get a fresh tree, and try again.

didn't happen with a debug build a few days ago, but with today's pull, apprunner does crash, when you try to trigger an invalid url. 1. go to http://jimbob/trigger.html 2. in the url field, type something like "http://jimbob/something.jar" 3. apprunner crashes Here is the stack trace from Win32. NTDLL! 77f76148() nsDebug::Assertion(const char * 0x0156f4b4, const char * 0x0156f494, const char * 0x0156f464, int 1051) line 274 + 13 bytes nsBoxFrame::FlowChildAt(nsIFrame * 0x02d5f040, nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 1, nsCalculatedBoxInfo & {...}, int & 1242232, nsString & {...}) line 1051 + 38 bytes nsBoxFrame::GetChildBoxInfo(nsIPresContext & {...}, const nsHTMLReflowState & {...}, nsIFrame * 0x02d5f040, nsCalculatedBoxInfo & {...}) line 365 nsBoxFrame::GetBoxInfo(nsBoxFrame * const 0x01f78df8, nsIPresContext & {...}, const nsHTMLReflowState & {...}, nsBoxInfo & {...}) line 1475 + 44 bytes nsBoxFrame::Reflow(nsBoxFrame * const 0x01f78dbc, nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 482 nsContainerFrame::ReflowChild(nsIFrame * 0x01f78db8, nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 372 + 28 bytes RootFrame::Reflow(RootFrame * const 0x02d5d034, nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 330 nsContainerFrame::ReflowChild(nsIFrame * 0x02d5d030, nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 372 + 28 bytes ViewportFrame::Reflow(ViewportFrame * const 0x02d517f4, nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 516 PresShell::InitialReflow(PresShell * const 0x02d088f0, int 6375, int 3375) line 889 XULDocumentImpl::StartLayout() line 4389 XULDocumentImpl::EndLoad(XULDocumentImpl * const 0x02d07e20) line 2120 XULContentSinkImpl::DidBuildModel(XULContentSinkImpl * const 0x02d15c70, int 1) line 528 CWellFormedDTD::DidBuildModel(CWellFormedDTD * const 0x02d15280, unsigned int 0, int 1, nsIParser * 0x02d11ca0, nsIContentSink * 0x02d15c70) line 287 + 20 bytes nsParser::DidBuildModel(unsigned int 0) line 547 + 55 bytes nsParser::ResumeParse(nsIDTD * 0x00000000, int 0) line 966 nsParser::EnableParser(int 1) line 642 + 15 bytes CSSLoaderImpl::Cleanup(URLKey & {...}, SheetLoadData * 0x02d4b8b0) line 629 CSSLoaderImpl::SheetComplete(nsICSSStyleSheet * 0x00000000, SheetLoadData * 0x02d4b8b0) line 705 CSSLoaderImpl::ParseSheet(nsIUnicharInputStream * 0x02d4e410, SheetLoadData * 0x02d4b8b0, int & 1, nsICSSStyleSheet * & 0x02d4e760) line 740 CSSLoaderImpl::DidLoadStyle(nsIUnicharStreamLoader * 0x02d4ee50, nsString & {...}, SheetLoadData * 0x02d4b8b0, unsigned int 0) line 773 + 24 bytes DoneLoadingStyle(nsIUnicharStreamLoader * 0x02d4ee50, nsString & {...}, void * 0x02d4b8b0, unsigned int 0) line 575 nsUnicharStreamLoader::OnStopRequest(nsUnicharStreamLoader * const 0x02d4ee54, nsIChannel * 0x02d4ed30, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x00000000) line 159 + 31 bytes nsChannelListener::OnStopRequest(nsChannelListener * const 0x02d4edc0, nsIChannel * 0x02d4ed30, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x00000000) line 1590 + 42 bytes nsFileChannel::OnStopRequest(nsFileChannel * const 0x02d4ed34, nsIChannel * 0x02d4eb80, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x00000000) line 466 + 45 bytes nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x02d4e690) line 283 nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x02d4e3b0) line 152 + 12 bytes PL_HandleEvent(PLEvent * 0x02d4e3b0) line 541 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00cfe990) line 500 + 9 bytes _md_EventReceiverProc(HWND__ * 0x0045021e, unsigned int 49450, unsigned int 0, long 13625744) line 970 + 9 bytes USER32! 77e71250() 00cfe990()

Eric, can you help take a look? -thanks!

I can't reach the test url. Can you put it somewhere I can reach it?

Which can't you reach? jimbob is within the firewall, is that the problem? The jar file mentioned in the test is a random garbage name and doesn't exist -- that's the point, we should handle that gracefully and not crash.

Ok I tried this. When I hit trigger a dialog calls me a punk and asks me if I want to download software. Dam upity panels. ;) Anyway another dialog then appears with a progress meter. Apprunner does not crash..

Build 1999-10-18-09-M11(WIN), 1999-10-18-12-M11(MAC), 1999-10-18-08-M11(LINUX) I am consistently crashing on all platforms as I originally described. I don't get it. Cyclone is currently inaccessible for me, so I'll have to enter the TalkBack info later.

this crash magically disappeared with today's build. marking bug WORKSFORME.

It turns out that the crash still exists. If you lead the string with http:// then there will not be a crash. This is different from before. Just follow the steps as originally described, and the crash will be duplicated.

Previous crash that I was talking about (using http:// or file:// pointing to a none existing file) was indeed disappeared, and browser no longer crashes. The crash that Jimmy reported, still exists. We can simply reproduce it by using a local path and triggers the file. steps to reproduce: 1. run mozilla.exe 2. go to http://jimbob/trigger2.html 3. in the url file, type in a platform specific local path, like c:\something.jar -- for windows my hard drive:something.jar -- for mac home/something.jar -- for unix 4. browser crashes Here is the stack trace from today's build: nsWebShellWindow::GetDOMNodeFromWebShell(nsIWebShell * 0x00000000) line 2212 + 27 bytes nsWebShellWindow::SetTitleFromXUL() line 2259 nsWebShellWindow::OnEndDocumentLoad(nsWebShellWindow * const 0x02fbd5bc, nsIDocumentLoader * 0x02fb8f60, nsIChannel * 0x02fbfe90, unsigned int 0, nsIDocumentLoaderObserver * 0x02fbd064) line 1997 nsWebShell::OnEndDocumentLoad(nsWebShell * const 0x02fbd064, nsIDocumentLoader * 0x02fb8f60, nsIChannel * 0x02fbfe90, unsigned int 0, nsIDocumentLoaderObserver * 0x02fbd064) line 3380 nsDocLoaderImpl::FireOnEndDocumentLoad(nsDocLoaderImpl * 0x02fb8f60, nsIChannel * 0x02fbfe90, unsigned int 0) line 849 nsDocLoaderImpl::OnStopRequest(nsDocLoaderImpl * const 0x02fb8f64, nsIChannel * 0x02f71390, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x00000000) line 730 nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x02f97490) line 322 nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x02f97440) line 169 + 12 bytes PL_HandleEvent(PLEvent * 0x02f97440) line 534 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x01fbda60) line 493 + 9 bytes _md_EventReceiverProc(HWND__ * 0x00fd0522, unsigned int 49427, unsigned int 0, long 33282656) line 963 + 9 bytes USER32! 77e71250() 01fbda60()

rick, something happened in the docloader... can you take a look at this bug?

Clearing WORKSFORME resolution due to reopen of this bug.

Looking at the stack trace, nsWebShellWindow::SetTitleFromXUL is passing null to nsWebShellWindow::GetDOMNodeFromWebShell. I don't think this is Rick's domain. Bill, can you look at this for him? (Maybe Vidur too.) Thanks.

OK, I'll have a look in a few minutes (with an up-to-date build).

Man, this makes about the third gnarly, timing-dependent, multi-threaded necko-related problem I've battled this week. First, I couldn't get the crash till I entered the bogus .jar file name and pressed OK on the "are you sure, punk" dialog. The crash occurs because the web shell window doesn't have a web shell anymore. This is odd. It happens to be doing "on load" processing, which just happens to be occuring at extremely odd times due to bug #17500. rpotts has recently fixed that, so I wonder if this problem might go away if I pick up his change. I'm going to try that before investing more time in understanding how we came to be in this situation.

http://jimbob/trigger2.html now causes a crash. I've opened bug #18359 and am making this on dependent on that one.

Well, since Chris Karnaze hasn't yet set a target milestone for, or even commented on, bug #18359, then I don't think were gonna get this one fixed for M11.

Moving this out to M12 ...

OK, the trigger2.html page now loads and we're back to where we were last time I commented on this. The mWebShell member of nsWebShellWindow is null and as far as I can tell that should never happen. I tried protecting the crash site with a null test but that just defers the crash till later on. I'm reassigning this to danm who will probably wish me dead for doing so. But he's the man when it comes to figuring out how opening new windows should work.

Mass-moving non-PDT+ bugs to M13

Bulk move of XPInstall (component to be deleted) bugs to Installer: XPInstall Engine

Appears fixed.

Build 2000-01-03-09-M13(WIN), 2000-01-03-08-M13(MAC), 2000-01-03-08-M13(LINUX) I'm no longer crashing. The XPInstall progress dialog appears briefly and then dismisses gracefully. However, it is not clear to me that specific action was taken to resolve this problem. I prefer to not see this problem return at a later date. Will somebody please provide some information to reassure us that this bug has been specifically addressed? Much appreciated. Reopening bug.

Clearing FIXED resolution due to reopen of this bug.

This bug was reopened, why, exactly? It was closed because no one can make it happen any more. If it makes you feel any better, code has been checked in in the past few weeks that makes window closing less dangerous. Likely one of those fixes caught this problem, too. Bugs go away like that all the time. I live for that. Reclosing. Feel free to hunt it down and reopen it if you see the bug return.

forced comment.

bite me, bugzilla.

Well, it is good to know that some code was checked in that relates to graceful window closing. Bugs just don't go away for free. Marking Verified.