42191 - Offline: SCRIPT SRC=file causes crash

Status: VERIFIED WORKSFORME

(Core :: Networking, defect, P3)

Description

[Koike Kazuhiko]

JavaScript file seems to cause crash on off-line mode.

(1) Make a html file which includes the following line.

<SCRIPT SRC="http://sitestatic.netscape.com/common/banner.js"></SCRIPT>

(2) Go off-line mode and open the file. Mozilla crashes.

Comment 1

[Alex]

Build ID 2000061308, Windows 98

I can confirm this, marking NEW.

Comment 2

[leger]

Adding crash keyword

Comment 3

[Phil Schwartau]

Browser issue, not engine -  reassigning 

Comment 4

[Doron Rosenberg (IBM)]

reporter - are you still seeing this with new builds? of yes, assign to dom level 0

Comment 5

[Asa Dotzler [:asa]]

crashes for me with 071008 mozilla talkback build.  stack trace below. updating 
componens and setting default owner.
 
   HTMLContentSink::ProcessSCRIPTTag 
                                       
[d:\builds\seamonkey\mozilla\layout\html\document\src\nsHTMLContentSink.cpp, 
line 4836]
     
   HTMLContentSink::AddLeaf 
                                       
[d:\builds\seamonkey\mozilla\layout\html\document\src\nsHTMLContentSink.cpp, 
line 3045]
     
   CNavDTD::AddLeaf 
                                       
[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 3499]
     
   CNavDTD::HandleScriptToken 
                                       
[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 2048]
     
   CNavDTD::OpenContainer 
                                       
[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 3176]
     
   CNavDTD::HandleDefaultStartToken 
                                       
[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 1140]
     
   CNavDTD::HandleStartToken 
                                       
[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 1530]
     
   CNavDTD::HandleToken 
                                       
[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 765]
     
   CNavDTD::BuildModel 
                                       
[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 504]
     
   nsParser::BuildModel 
                                       
[d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 1983]
     
   nsParser::ResumeParse 
                                       
[d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 1862]
     
   nsParser::OnDataAvailable 
                                       
[d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 2313]
     
   nsDocumentOpenInfo::OnDataAvailable 
                                       
[d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp, line 252]
     
   nsFileChannel::OnDataAvailable 
                                       
[d:\builds\seamonkey\mozilla\netwerk\protocol\file\src\nsFileChannel.cpp, line 
661]
     
   nsOnDataAvailableEvent::HandleEvent 
                                       
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 
407]
     
   nsStreamListenerEvent::HandlePLEvent
                                       
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 
106]
     
   PL_HandleEvent 
                                       
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 588]
     
   PL_ProcessPendingEvents 
                                       
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 547]
     
   _md_EventReceiverProc 
                                       
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1045]
     
   USER32.dll + 0x1820 (0x77e71820) 

Comment 6

[rods (gone)]

jst, could you take a look at this or assign it to the right person? Thanks.

Comment 7

[Johnny Stenback (:jst)]

Attachment: Simple testcase

Comment 8

[Johnny Stenback (:jst)]

I see this on WinNT and linux, looks like this is a necko problem, necko
basically does (in NS_NewStreamLoader()):

    rv = nsComponentManager::CreateInstance(kStreamLoaderCID, nsnull,
                                            NS_GET_IID(nsIStreamLoader),
                                            getter_AddRefs(loader));
    if (NS_FAILED(rv)) return rv;
    rv = loader->Init(uri, observer, context, loadGroup, ...);
    if (NS_FAILED(rv)) return rv;
    *result = loader;
    NS_ADDREF(*result);
    return rv;

The loader is properly created but when loader->Init() is called
(layer->mRefCnt is 1) the loader is deleted, so we crash at NS_ADDREF(*result)
(*result is the deleted loader).

Over to gagan for futher investigation...

Comment 9

[Gagan]

this looks bad. we shouldn't return NS_OK on that Init. 

Comment 10

[Phil Peterson]

Not holding PR3 for this; marking nsbeta3-. Please nominate for RTM if we really
need to fix this before shipping Seamonkey.

Comment 11

[Koike Kazuhiko]

WORKSFORME with 2000112204-Mtrunk/Win98.

Comment 12

[Hixie (not reading bugmail)]

Upon managerial request, adding the "testcase" keyword to 84 open layout bugs that
do not have the "testcase" keyword and yet have an attachement with the word
"test" in the description field. Apologies for any mistakes.

Comment 13

[karnaze (gone)]

Reassigning to module owner.

Comment 14

[karnaze (gone)]

Reassigning to javascript module owner.

Comment 15

[Brendan Eich [:brendan]]

karnaze: did you read this bug?  The crash stacks and faulty code have nothing
to do with the JS engine.  I'm not sure why you took the bug, briefly, but it
looks like it should stay in Necko-land, this time with a real, still-present
hacker/manager: gagan.

/be

Comment 16

[Phil Schwartau]

Setting default QA -

Comment 17

[Gagan]

Hmmm.... seems like this must have slipped between the cracks. But anyhow... I 
am not having any problems with this. Seeing no crash with today's build. Anyone 
else confirm this? if so then its a worksforme-thru-a-miraculous-anonymous-fix 
:)

Comment 18

[Gagan]

wfm

Comment 19

[benc]

reporter:

This bug is a "futured" or "untargeted" bug which has been "resolved/works for
me". Most bugs meeting this criteria are usually somewhat out of date or working
in the current builds.

If this bug is not happening for you in a recent build (such as the Mozilla
daily build, Mozilla 0.9.3, or Netscape 6.1), please use the friendly "Mark bugs
as VERIFIED" radio button to set this bug to "VERIFIED/WORKS FOR ME"
If you reported the bug on a platform (e.g. Linux) and other contributors
reported on another platform (e.g. Mac OS), please comment that it works for you
 but do not verify it yet.

For these multi-platform bug reports, we need to verify all reported platforms
-OR- create new "still broken on platform X" bugs when you verify.

Comment 20

[benc]

reporter: does this still happen to you?

Comment 21

[Koike Kazuhiko]

Verified.