Closed Bug 15209 Opened 25 years ago Closed 25 years ago

Crash when triggering with incorrect path to any jar file

Categories

(Core Graveyard :: Installer: XPInstall Engine, defect, P3)

All
Windows 98
defect

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: jimmykenlee, Assigned: danm.moz)

References

Details

(Whiteboard: nsWebShellWindow::SetTitleFromXUL passed NULL and crashes)

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()
Assignee: cathleen → evaughan
Eric, can you help take a look?  -thanks!
Status: NEW → ASSIGNED
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
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..
Status: RESOLVED → REOPENED
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.
Assignee: evaughan → cathleen
Status: REOPENED → NEW
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()
Assignee: cathleen → rpotts
Target Milestone: M11
rick, something happened in the docloader...
can you take a look at this bug?
Resolution: WORKSFORME → ---
Clearing WORKSFORME resolution due to reopen of this bug.
Assignee: rpotts → law
Whiteboard: nsWebShellWindow::SetTitleFromXUL passed NULL and crashes
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.
Status: NEW → ASSIGNED
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.
Depends on: 18359
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.
Target Milestone: M11 → M12
Moving this out to M12 ...
Assignee: law → danm
Status: ASSIGNED → NEW
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
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
Appears fixed.
Status: RESOLVED → REOPENED
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.
Resolution: FIXED → ---
Clearing FIXED resolution due to reopen of this bug.
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: FIXED → WORKSFORME
forced comment.
bite me, bugzilla.
Status: RESOLVED → VERIFIED
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.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.