Browser crashes entering listed URL

VERIFIED FIXED in mozilla0.9



JavaScript Engine
17 years ago
17 years ago


(Reporter: tracy, Assigned: brendan)


({crash, js1.5})

crash, js1.5

Firefox Tracking Flags

(Not tracked)




(5 attachments)



17 years ago
seen on commercial builds:

windows 2001-02-19-06-mtrunk
linux 2001-02-19-06-mtrunk
mac 2001-02-19-04-trunk

attempts to open the listed URL crash the browser every time.  This page is one 
of many used in performance testing.  The test can not complete because of the 

Note: the browser doesn't crash when going to the current dynamic version of

Comment 1

17 years ago
I can't reproduce this because lacks a DNS entry.
Keywords: crash

Comment 2

17 years ago
this url is MozillaCommunications internal. please make a public version 
available if possible, or move to bugscape.
Keywords: nsonly

Comment 3

17 years ago
   js_EmitTree   [d:\builds\seamonkey\mozilla\js\src\jsemit.c, line 903]       
 js_EmitTree   [d:\builds\seamonkey\mozilla\js\src\jsemit.c, line 2443]        
js_EmitTree   [d:\builds\seamonkey\mozilla\js\src\jsemit.c, line 2057]        
Statements   [d:\builds\seamonkey\mozilla\js\src\jsparse.c, line 859]        
js_CompileTokenStream   [d:\builds\seamonkey\mozilla\js\src\jsparse.c, line 391]
        CompileTokenStream   [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line
2734]         JS_CompileUCScriptForPrincipals  
[d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 2812]        
JS_EvaluateUCScriptForPrincipals   [d:\builds\seamonkey\mozilla\js\src\jsapi.c,
line 3219]         nsJSContext::EvaluateString  
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 610]       
line 4689]         HTMLContentSink::ProcessSCRIPTTag  
line 5043]         HTMLContentSink::AddLeaf  
line 3193]         CNavDTD::AddLeaf  
[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 3754]        
[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 2189]        
[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 3418]        
[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 1255]        
[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 1664]        
CNavDTD::HandleToken   [d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp,
line 833]         CNavDTD::BuildModel  
[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 523]        
nsParser::BuildModel   [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp,
line 2032]         nsParser::ResumeParse  
[d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 1911]        
[d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 1523]        
line 4827]         nsStreamLoader::OnStopRequest  
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamLoader.cpp, line 123]    
line 1184]         InterceptStreamListener::OnStopRequest  
[d:\builds\seamonkey\mozilla\netwerk\cache\mgr\nsCachedNetData.cpp, line 1212] 
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPChannel.cpp, line
1944]         nsHTTPServerListener::OnStopRequest  
line 735]         nsOnStopRequestEvent::HandleEvent  
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamObserverProxy.cpp, line
178]         nsStreamObserverEvent::HandlePLEvent  
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamObserverProxy.cpp, line
78]         PL_HandleEvent  
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 577]        
PL_ProcessPendingEvents   [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c,
line 513]         _md_EventReceiverProc  
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1055]
Assignee: asa → rogerl
Component: Browser-General → Javascript Engine
QA Contact: doronr → pschwartau

Comment 4

17 years ago
cc'ing Brendan, jband - 

Note: my debug browser failed to build today on either WinNT or Linux; 
will have to try again later - 

Comment 5

17 years ago
Shaver, I haven't quite grokked this, but it looks related to your fix to bug
69304.  I'll help fix it.

Assignee: rogerl → shaver
I'll poke at it, but it'll be a lot easier with a test case I can see.  Many
bonus points -- and a faster fix! -- for one I can run in the shell. 
pschwartau, can you help here?

Comment 7

17 years ago

Regression from bug 68498 ? Shaver's fix for bug 69304 wasn't wrong was it?

I see this on a new mozilla build that contains brendan's changes from 
yesterday. I'll attach a stack with param values. It is crashing because the 
next to last stack has a pn2 of null in:

      case TOK_NEW:
      case TOK_LP:
         * Emit function call or operator new (constructor call) code.
         * First, emit code for the left operand to evaluate the callable or
         * constructable object expression.
        pn2 = pn->pn_head;
        if (!js_EmitTree(cx, cg, pn2))
            return JS_FALSE;

The script being compiled is a big old thing with length of 505

Comment 8

17 years ago
Created attachment 25650 [details]
stack of crash w/ param values

Comment 9

17 years ago
removing nsonly keyword. This crashes mozilla.exe for me. Is there a copy of 
this test outside the NS firewall?
Keywords: nsonly
jband: can you scavenge the to-be-compiled script string for me?  It'll help

Comment 11

17 years ago
jband: bug 68498 is an obj.eval(str) problem.  I bet this bug is simply a latent
one in the constant folder and/or the code generator, that shaver's fix for bug
69304 exposed.  Thing is, I don't see why any folder or simplifier should ever
leave a TOK_LP or TOK_NEW node that has a null pn_head.


Comment 12

17 years ago
Created attachment 25652 [details]
the full <script> tag block whose contents it seems to be handling

Comment 13

17 years ago
Created attachment 25654 [details]
this is the html file which crashes me

Comment 14

17 years ago
Created attachment 25657 [details]
tar.gz of an old, static version of

Comment 15

17 years ago
Sorry, but I missed the significance of the summary for this bug (among my 
pile of bugzilla email). The content is just a "captured" version of 
voodooextreme from mid-December 2000. No major modifications were made, 
other than to rewrite URL's, kill's and redirects, etc.

Comment 16

17 years ago
Yup, latent bug in the case folder, added when I added parsenode recycling. 
Patch coming up.  Looking for fast r/sr= and an open tree -- don't fence me in!

Assignee: shaver → brendan
Keywords: js1.5, mozilla0.9
Priority: -- → P1
Target Milestone: --- → mozilla0.9


17 years ago

Comment 17

17 years ago
Created attachment 25658 [details] [diff] [review]
proposed fix

Comment 18

17 years ago
PN_COPY_OVER(pn, pn2) did what it said, but that was before i violated the very
thin abstraction here by recycling pn2 afterwards.  Now it's PN_MOVE_NODE, which
zaps pn2 so as to hand off its kid(s) to pn.  Thicker abstraction, but still
macro-wafer-thin; yum.


Comment 19

17 years ago
s/case folder/constant folder/

Looks tasty to me.  r=shaver

Comment 21

17 years ago

Comment 22

17 years ago
Fix is in, thanks.

Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 23

17 years ago
Heh. I just remembered that I rewrote that line to do 'if (true) ...',
since I wanted a constant code path, but still making the JS be compiled
and the HTML to be inserted through script. Oh, well. Unintended latent
bug finder. 

    var ew = Math.random() * 3;
!   if (true) document.write('...
    else if (ew < 2) document.write ('...
    else document.write ('...

Comment 24

17 years ago
verified fixed on linux commercial build 2001-02-21-06-mtrunk
You need to log in before you can comment on or make changes to this bug.