503144 - Crash in [@ js3250.dll@0x68bec] [@ specializeTreesToMissingGlobals(JSContext*, TreeInfo*) ] visiting certain pages

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Tobias (:Tobbi) Markus]

As per https://support.mozilla.com/tiki-view_forum_thread.php?forumId=1&comments_parentId=384001#threadId386915 some users are having problems visiting websites or uploading data to webservers. 

A crash report associated with this issue can be found here:
http://crash-stats.mozilla.com/report/index/65f3ab41-5960-4cb6-a270-cbaee2090708?p=1

As you can see in the forum post, there are two users experiencing the same problem. I could reproduce it with 
Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729)

Steps to reproduce:
1. Go to http://www.solarlog-home.de/rosenhammer/visu.html 
2. Randomly navigate to the site. It didn't crash the first time for me but did after I clicked somewhere.

Comment 1

[Matthew Middleton (:zzxc)]

In Linux, the same testcase crashed with bp-28309a1f-62ec-41bc-9a0b-d75812090708

Comment 2

[David Delony]

In Mac OS X, the latest nightly crashed with: d4a9dbb6-caa9-4dd2-a789-b71132090708

Build info: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090708 Minefield/3.6a1pre

Comment 3

[Ria Klaassen (not reading all bugmail)]

Is not consistently to reproduce here on Vista. Four times in a row but then it stopped.

Comment 4

[Bob Clary [:bc] (inactive)]

testcase keyword is used to indicate an attached or inline test independent of the original crashing page.

Comment 5

[Aaron Train [:aaronmt]]

This bug (or rather the test URL) here is very annoying because the crash is occurring on load only at certain times of the day depending on the pages data update and whatever the data is. 

The log of the day is in min_day.js and the crash probably has something to do with these large array.

http://www.solarlog-home.de/rosenhammer/min_day.js

Comment 6

[pourlp]

I have the same problem (not always) on this website : http://www.autotitre.com/

It contains a ""little" array, search "var lstcon=new Array" on the page.

Comment 7

[Jesse Ruderman]

I can't reproduce this bug using Firefox 3.5 on Mac.  If someone can create a self-contained testcase, and I can reproduce using that, I can also help reduce.

https://developer.mozilla.org/en/Reducing_testcases
http://www.squarefree.com/2009/01/11/reducing-real-world-scripts/

Comment 8

[pourlp]

It seems that it happen only on windows : http://crash-stats.mozilla.com/query/query?do_query=1&product=Firefox&version=Firefox%3A3.5&date=&range_value=1&range_unit=weeks&query_search=signature&query_type=exact&query=js3250.dll%400x68bec

The page http://www.solarlog-home.de/rosenhammer/visu.html always crash firefox on my pc, I don't have found why, It does not happen in safe-mode, but it happens in normal mode with no extension, no plugins and default theme.

Comment 9

[David Anderson [:dvander] - inactive, e-mail if emergency]

(In reply to comment #8)
I can reproduce this in 3.5 w/ OS X. Investigating

Comment 10

[Jesse Ruderman]

pourlp, this bug wouldn't happen in safe mode because safe mode disables the JIT (see bug 453642 and bug 478846).

Comment 11

[Jesse Ruderman]

Attachment: stack trace (mac, debug, url from comment 8)

Comment 12

[Jesse Ruderman]

dangit, now i can't repro

Comment 13

[u348128]

The crash is dependent on the data. As far I can see, the data is loaded by javascripts (not HTTPrequest):

<script language="JavaScript"src="min_cur.js?nocache"></script>
<script language="JavaScript"src="min_day.js?nocache"></script>
<script language="JavaScript"src="days.js?nocache"></script>
<script language="JavaScript"src="days_hist.js?nocache"></script>
<script language="JavaScript"src="months.js?nocache"></script>
<script language="JavaScript"src="years.js?nocache"></script>
<script language="JavaScript"src="diagram.js"></script></head>

I could reproduce it today, but not now anymore. So, if it reproduces, we have to copy those scripts.

It could be a duplicate of bug 503286. In the current 3.5 version, the 'escape' function is broken and can crash the browser. This page uses the 'escape' function.

Lucas

Comment 14

[u348128]

The site: http://www.autotitre.com/

also uses the escape function.

Comment 15

[pourlp]

Attachment: This page will crash FF 3.5

A little page to crash FF 3.5

If you delete something in the page, FF may not crash. For exemple, if you delete the empty line n°31 or js comments, FF will work.

I hope it can help you.

Comment 16

[Aaron Train [:aaronmt]]

(In reply to comment #14)
> The site: http://www.autotitre.com/
> 
> also uses the escape function.

function txt2URI (t){
  t=String(t);var e = escape;return e(t).replace(/\+/g,"%2B");
}

Comment 17

[u348128]

The attachment of pourlp (#15) gives the right signature, and does not contain the 'escape' function. So, this bug is not a dupe of of bug 503286.

Comment 18

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Stacks show that there are scary addresses, so turning security-sensitive just to be safe.

Comment 19

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: fully reduced testcase

Fully reduced testcase from pourlp's. Run this from the CLI in linux to crash.

$ ./firefox -g
./run-mozilla.sh -g ./firefox-bin
MOZILLA_FIVE_HOME=.
  LD_LIBRARY_PATH=.:./plugins:.
DISPLAY=:0.0
DYLD_LIBRARY_PATH=.:.
     LIBRARY_PATH=.:./components:.
       SHLIB_PATH=.:.
          LIBPATH=.:.
       ADDON_PATH=.
      MOZ_PROGRAM=./firefox-bin
      MOZ_TOOLKIT=
        moz_debug=1
     moz_debugger=
/usr/bin/gdb ./firefox-bin -x /tmp/mozargs.DyBxmZ
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(gdb) r ~/Desktop/crashFF3.5_js3250.html 

/snip

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb6e40750 (LWP 24254)]
0xb7fb22c2 in Queue<unsigned char>::length (this=0x5a5a5a6e) at /home/fuzz4/mozilla-1.9.1/js/src/jstracer.h:124
124	        return _len;
(gdb) bt
#0  0xb7fb22c2 in Queue<unsigned char>::length (this=0x5a5a5a6e) at /home/fuzz4/mozilla-1.9.1/js/src/jstracer.h:124
#1  0xb7fb22dc in TreeInfo::nGlobalTypes (this=0x5a5a5a5a) at /home/fuzz4/mozilla-1.9.1/js/src/jstracer.h:371
#2  0xb7f88bdc in specializeTreesToMissingGlobals (cx=0xb1f30800, root=0xb121d2e0) at /home/fuzz4/mozilla-1.9.1/js/src/jstracer.cpp:1346
#3  0xb7f88d81 in js_CheckEntryTypes (cx=0xb1f30800, ti=0xb121d2e0) at /home/fuzz4/mozilla-1.9.1/js/src/jstracer.cpp:4365
#4  0xb7f89656 in js_FindVMCompatiblePeer (cx=0xb1f30800, f=0xb152a870, count=@0xbf8e3768) at /home/fuzz4/mozilla-1.9.1/js/src/jstracer.cpp:4405
#5  0xb7fb1a23 in js_MonitorLoopEdge (cx=0xb1f30800, inlineCallCount=@0xbf8e3f9c) at /home/fuzz4/mozilla-1.9.1/js/src/jstracer.cpp:4848
#6  0xb7eba2f4 in js_Interpret (cx=0xb1f30800) at /home/fuzz4/mozilla-1.9.1/js/src/jsinterp.cpp:3308
#7  0xb7ee64a9 in js_Execute (cx=0xb1f30800, chain=0xb121c100, script=0xb15e7ab0, down=0x0, flags=0, result=0x0) at /home/fuzz4/mozilla-1.9.1/js/src/jsinterp.cpp:1622
#8  0xb7e57ba4 in JS_EvaluateUCScriptForPrincipals (cx=0xb1f30800, obj=0xb121c100, principals=0xb15e7424, chars=0xbf8e42cc, length=5, 
    filename=0xb1940d68 "file:///home/fuzz4/Desktop/crashFF3.5_js3250.html", lineno=17, rval=0x0) at /home/fuzz4/mozilla-1.9.1/js/src/jsapi.cpp:5145
#9  0xb2db03bf in nsJSContext::EvaluateString (this=0xb20a4610, aScript=@0xbf8e42b8, aScopeObject=0xb121c100, aPrincipal=0xb15e7420, 
    aURL=0xb1940d68 "file:///home/fuzz4/Desktop/crashFF3.5_js3250.html", aLineNo=17, aVersion=0, aRetValue=0x0, aIsUndefined=0xbf8e41f4)
    at /home/fuzz4/mozilla-1.9.1/dom/src/base/nsJSEnvironment.cpp:1631
#10 0xb2b7a1b1 in nsScriptLoader::EvaluateScript (this=0xb1209d00, aRequest=0xb61c3160, aScript=@0xbf8e42b8) at /home/fuzz4/mozilla-1.9.1/content/base/src/nsScriptLoader.cpp:686
#11 0xb2b7a48d in nsScriptLoader::ProcessRequest (this=0xb1209d00, aRequest=0xb61c3160) at /home/fuzz4/mozilla-1.9.1/content/base/src/nsScriptLoader.cpp:600
#12 0xb2b7c5dc in nsScriptLoader::ProcessScriptElement (this=0xb1209d00, aElement=0xb12324e4) at /home/fuzz4/mozilla-1.9.1/content/base/src/nsScriptLoader.cpp:554
#13 0xb2b77cbf in nsScriptElement::MaybeProcessScript (this=0xb12324e4) at /home/fuzz4/mozilla-1.9.1/content/base/src/nsScriptElement.cpp:193
#14 0xb2c50010 in nsHTMLScriptElement::MaybeProcessScript (this=0xb12324c0) at /home/fuzz4/mozilla-1.9.1/content/html/content/src/nsHTMLScriptElement.cpp:546
#15 0xb2c4e681 in nsHTMLScriptElement::DoneAddingChildren (this=0xb12324c0, aHaveNotified=1) at /home/fuzz4/mozilla-1.9.1/content/html/content/src/nsHTMLScriptElement.cpp:483
#16 0xb2c815fb in HTMLContentSink::ProcessSCRIPTEndTag (this=0xb15c7400, content=0xb12324c0, aMalformed=0) at /home/fuzz4/mozilla-1.9.1/content/html/document/src/nsHTMLContentSink.cpp:3145
#17 0xb2c8273b in SinkContext::CloseContainer (this=0xb1220f70, aTag=eHTMLTag_script, aMalformed=0) at /home/fuzz4/mozilla-1.9.1/content/html/document/src/nsHTMLContentSink.cpp:1022
#18 0xb2c82dc6 in HTMLContentSink::CloseContainer (this=0xb15c7400, aTag=eHTMLTag_script) at /home/fuzz4/mozilla-1.9.1/content/html/document/src/nsHTMLContentSink.cpp:2396
#19 0xb22965f7 in CNavDTD::CloseContainer (this=0xb15fd300, aTag=eHTMLTag_script, aMalformed=0) at /home/fuzz4/mozilla-1.9.1/parser/htmlparser/src/CNavDTD.cpp:2804
#20 0xb2299e73 in CNavDTD::HandleEndToken (this=0xb15fd300, aToken=0xb12110d0) at /home/fuzz4/mozilla-1.9.1/parser/htmlparser/src/CNavDTD.cpp:1683
#21 0xb229c285 in CNavDTD::HandleToken (this=0xb15fd300, aToken=0xb12110d0, aParser=0xb152a5b0) at /home/fuzz4/mozilla-1.9.1/parser/htmlparser/src/CNavDTD.cpp:760
#22 0xb229904a in CNavDTD::BuildModel (this=0xb15fd300, aParser=0xb152a5b0, aTokenizer=0xb15e79c0, anObserver=0x0, aSink=0xb15c74b4)
    at /home/fuzz4/mozilla-1.9.1/parser/htmlparser/src/CNavDTD.cpp:332
#23 0xb22a7239 in nsParser::BuildModel (this=0xb152a5b0) at /home/fuzz4/mozilla-1.9.1/parser/htmlparser/src/nsParser.cpp:2400
#24 0xb22ad319 in nsParser::ResumeParse (this=0xb152a5b0, allowIteration=1, aIsFinalChunk=0, aCanInterrupt=1) at /home/fuzz4/mozilla-1.9.1/parser/htmlparser/src/nsParser.cpp:2273
#25 0xb22ae932 in nsParser::OnDataAvailable (this=0xb152a5b0, request=0xb17b7690, aContext=0x0, pIStream=0xb17b784c, sourceOffset=0, aLength=210)
    at /home/fuzz4/mozilla-1.9.1/parser/htmlparser/src/nsParser.cpp:2926
#26 0xb25fb421 in nsDocumentOpenInfo::OnDataAvailable (this=0xb1571040, request=0xb17b7690, aCtxt=0x0, inStr=0xb17b784c, sourceOffset=0, count=210)
    at /home/fuzz4/mozilla-1.9.1/uriloader/base/nsURILoader.cpp:306
#27 0xb5eabcdc in nsBaseChannel::OnDataAvailable (this=0xb17b7660, request=0xb1940dc0, ctxt=0x0, stream=0xb17b784c, offset=0, count=210)
    at /home/fuzz4/mozilla-1.9.1/netwerk/base/src/nsBaseChannel.cpp:708
#28 0xb5ec03d2 in nsInputStreamPump::OnStateTransfer (this=0xb1940dc0) at /home/fuzz4/mozilla-1.9.1/netwerk/base/src/nsInputStreamPump.cpp:508
#29 0xb5ec0929 in nsInputStreamPump::OnInputStreamReady (this=0xb1940dc0, stream=0xb17b784c) at /home/fuzz4/mozilla-1.9.1/netwerk/base/src/nsInputStreamPump.cpp:398
#30 0xb7dac420 in nsInputStreamReadyEvent::Run (this=0xb1565f60) at /home/fuzz4/mozilla-1.9.1/xpcom/io/nsStreamUtils.cpp:111
#31 0xb7ddb015 in nsThread::ProcessNextEvent (this=0xb6bc6c40, mayWait=1, result=0xbf8e4e80) at /home/fuzz4/mozilla-1.9.1/xpcom/threads/nsThread.cpp:510
#32 0xb7d66b10 in NS_ProcessNextEvent_P (thread=0xb6bc6c40, mayWait=1) at nsThreadUtils.cpp:227
#33 0xb4daf7ae in nsBaseAppShell::Run (this=0xb6a4d5b0) at /home/fuzz4/mozilla-1.9.1/widget/src/xpwidgets/nsBaseAppShell.cpp:170
#34 0xb4a68f61 in nsAppStartup::Run (this=0xb61b03d0) at /home/fuzz4/mozilla-1.9.1/toolkit/components/startup/src/nsAppStartup.cpp:193
#35 0xb8061d49 in XRE_main (argc=2, argv=0xbf8e5534, aAppData=0xb6b06540) at /home/fuzz4/mozilla-1.9.1/toolkit/xre/nsAppRunner.cpp:3298
#36 0x08049a62 in main (argc=2, argv=0xbf8e5534) at /home/fuzz4/mozilla-1.9.1/browser/app/nsBrowserApp.cpp:156
(gdb) l
119	    const T & get(unsigned i) const {
120	        return _data[i];
121	    }
122	
123	    unsigned length() const {
124	        return _len;
125	    }
126	
127	    T* data() const {
128	        return _data;
(gdb) p _len
Cannot access memory at address 0x5a5a5a72
(gdb)

Comment 20

[David Anderson [:dvander] - inactive, e-mail if emergency]

Nice test case reductions. I was having trouble reproducing this on trunk, but the problem is definitely in trashed trees lying around.

I recall dmandelin fixing a bug like this, so I looked at his recent csets:

http://hg.mozilla.org/tracemonkey/rev/e7c61fb767c7

I don't have access to bug 496391 but it looks like it hasn't landed on either 1.9.1 or central yet.

Comment 21

[u348128]

For verification. I have copied crashing solar data to page:

http://web.inter.nl.net/users/L.B.Kruijswijk/FFsolarcrash/solar.html

I still miss some files. But if you click on 'reload' a few times very fast, then it crashes.

Not for reduction, but for verification.

Comment 22

[Robert Sayre]

(In reply to comment #20)
> Nice test case reductions. I was having trouble reproducing this on trunk, but
> the problem is definitely in trashed trees lying around.
> 
> I recall dmandelin fixing a bug like this, so I looked at his recent csets:
> 
> http://hg.mozilla.org/tracemonkey/rev/e7c61fb767c7
> 
> I don't have access to bug 496391 but it looks like it hasn't landed on either
> 1.9.1 or central yet.

That doesn't sound right. That bug was fixed for release, iirc.

Comment 23

[Nochum Sossonko [:Natch]]

Attachment: stack, Gary's testcase

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090714 Minefield/3.6a1pre

Crashes on TM tip as well, so that cset can't have fixed it (or it regressed since then).

Comment 24

[pourlp]

Same problem with Firefox 3.5.1 but the new signature is js3250.dll@0x68b5b

http://crash-stats.mozilla.com/report/list?query_search=signature&signature=js3250.dll%400x68b5b

I don't know how to say the signature js3250.dll@0x68b5b rely on this bug on crash-stats

Comment 25

[Andreas Gal :gal]

http://www.solarlog-home.de/rosenhammer/visu.html

definitively crashes us. The near-NULL crash is misleading. The value is coming from the heap, so it might be not near-NULL in other cases.

We need a reduced test case.

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000020
0x003d44bb in Queue<JSTraceType_>::length (this=0x1c) at jstracer.h:133
133	        return _len;
(gdb) bt
#0  0x003d44bb in Queue<JSTraceType_>::length (this=0x1c) at jstracer.h:133
#1  0x003d44d4 in TreeInfo::nGlobalTypes (this=0x8) at jstracer.h:467
#2  0x003b7701 in specializeTreesToMissingGlobals (cx=0x13e8600, globalObj=0x16fd9200, root=0x86afe0) at ../../../js/src/jstracer.cpp:1558
#3  0x003d220c in TraceRecorder::findNestedCompatiblePeer (this=0x868f60, f=0x86dc30) at ../../../js/src/jstracer.cpp:5004
#4  0x003d2721 in js_RecordLoopEdge (cx=0x13e8600, r=0x868f60, inlineCallCount=@0xbfffc9b8) at ../../../js/src/jstracer.cpp:4807
#5  0x003d3165 in js_MonitorLoopEdge (cx=0x13e8600, inlineCallCount=@0xbfffc9b8) at ../../../js/src/jstracer.cpp:5511
#6  0x002edacf in js_Interpret (cx=0x13e8600) at ../../../js/src/jsinterp.cpp:3926
#7  0x0030fb0c in js_Execute (cx=0x13e8600, chain=0x16fd9200, script=0x107b400, down=0x0, flags=0, result=0x0) at jsinterp.cpp:1635
#8  0x0028d6b1 in JS_EvaluateUCScriptForPrincipals (cx=0x13e8600, obj=0x16fd9200, principals=0x17cab354, chars=0x1579808, length=614, filename=0x17c0b088 "http://www.solarlog-home.de/rosenhammer/visu.html", lineno=1828, rval=0x0) at ../../../js/src/jsapi.cpp:5157
#9  0x18fd8a33 in nsJSContext::EvaluateString (this=0x1cee2020, aScript=@0xbfffd064, aScopeObject=0x16fd9200, aPrincipal=0x17cab350, aURL=0x17c0b088 "http://www.solarlog-home.de/rosenhammer/visu.html", aLineNo=1828, aVersion=0, aRetValue=0x0, aIsUndefined=0xbfffcfe4) at ../../../dom/base/nsJSEnvironment.cpp:1682
#10 0x18dac38e in nsScriptLoader::EvaluateScript (this=0x17cab270, aRequest=0x8669b0, aScript=@0xbfffd064) at ../../../../content/base/src/nsScriptLoader.cpp:686
#11 0x18dac634 in nsScriptLoader::ProcessRequest (this=0x17cab270, aRequest=0x8669b0) at ../../../../content/base/src/nsScriptLoader.cpp:600
#12 0x18dad89a in nsScriptLoader::ProcessScriptElement (this=0x17cab270, aElement=0x866964) at ../../../../content/base/src/nsScriptLoader.cpp:554
#13 0x18da8ea6 in nsScriptElement::MaybeProcessScript (this=0x866964) at ../../../../content/base/src/nsScriptElement.cpp:193
#14 0x18e7c7b5 in nsHTMLScriptElement::MaybeProcessScript (this=0x866940) at ../../../../../content/html/content/src/nsHTMLScriptElement.cpp:547
#15 0x18e7ba69 in nsHTMLScriptElement::DoneAddingChildren (this=0x866940, aHaveNotified=1) at ../../../../../content/html/content/src/nsHTMLScriptElement.cpp:484
#16 0x18eac939 in HTMLContentSink::ProcessSCRIPTEndTag (this=0x15a9400, content=0x866940, aMalformed=0) at ../../../../../content/html/document/src/nsHTMLContentSink.cpp:3096
#17 0x18ead8e7 in SinkContext::CloseContainer (this=0x17cab860, aTag=eHTMLTag_script, aMalformed=0) at ../../../../../content/html/document/src/nsHTMLContentSink.cpp:1014
#18 0x18eb0025 in HTMLContentSink::CloseContainer (this=0x15a9400, aTag=eHTMLTag_script) at ../../../../../content/html/document/src/nsHTMLContentSink.cpp:2376
#19 0x1cb28728 in CNavDTD::CloseContainer (this=0x17cb5340, aTag=eHTMLTag_script, aMalformed=0) at ../../../../parser/htmlparser/src/CNavDTD.cpp:2762
#20 0x1cb2c137 in CNavDTD::HandleEndToken (this=0x17cb5340, aToken=0x1d0dfd20) at ../../../../parser/htmlparser/src/CNavDTD.cpp:1641
#21 0x1cb2aabc in CNavDTD::HandleToken (this=0x17cb5340, aToken=0x1d0dfd20) at ../../../../parser/htmlparser/src/CNavDTD.cpp:721
#22 0x1cb2c858 in CNavDTD::BuildModel (this=0x17cb5340, aTokenizer=0x17cb5400, aCanInterrupt=1, aCountLines=1) at ../../../../parser/htmlparser/src/CNavDTD.cpp:304
#23 0x1cb3754f in nsParser::BuildModel (this=0x17cab6b0) at ../../../../parser/htmlparser/src/nsParser.cpp:2452
#24 0x1cb3ce33 in nsParser::ResumeParse (this=0x17cab6b0, allowIteration=1, aIsFinalChunk=1, aCanInterrupt=1) at ../../../../parser/htmlparser/src/nsParser.cpp:2333
#25 0x1cb3d773 in nsParser::ContinueInterruptedParsing (this=0x17cab6b0) at ../../../../parser/htmlparser/src/nsParser.cpp:1829
#26 0x1cb35ed3 in nsParser::HandleParserContinueEvent (this=0x17cab6b0, ev=0x1c4a8300) at ../../../../parser/htmlparser/src/nsParser.cpp:1897
#27 0x1cb3f737 in nsParserContinueEvent::Run (this=0x1c4a8300) at ../../../../parser/htmlparser/src/nsParser.cpp:164
#28 0x0057d3be in nsThread::ProcessNextEvent (this=0x8153d0, mayWait=0, result=0xbfffdb94) at ../../../xpcom/threads/nsThread.cpp:527
#29 0x00502642 in NS_ProcessPendingEvents_P (thread=0x8153d0, timeout=20) at nsThreadUtils.cpp:180
#30 0x118c1257 in nsBaseAppShell::NativeEventCallback (this=0x8435f0) at ../../../../widget/src/xpwidgets/nsBaseAppShell.cpp:121
#31 0x11877516 in nsAppShell::ProcessGeckoEvents (aInfo=0x8435f0) at ../../../../widget/src/cocoa/nsAppShell.mm:413
#32 0x92da8595 in CFRunLoopRunSpecific ()
#33 0x92da8c78 in CFRunLoopRunInMode ()
#34 0x94fdc28c in RunCurrentEventLoopInMode ()
#35 0x94fdc0a5 in ReceiveNextEventCommon ()
#36 0x94fdbf19 in BlockUntilNextEventMatchingListInMode ()
#37 0x9340ad0d in _DPSNextEvent ()
#38 0x9340a5c0 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#39 0x934035fb in -[NSApplication run] ()
#40 0x11875540 in nsAppShell::Run (this=0x8435f0) at ../../../../widget/src/cocoa/nsAppShell.mm:766
#41 0x1252fda6 in nsAppStartup::Run (this=0x85d1f0) at ../../../../../toolkit/components/startup/src/nsAppStartup.cpp:193
#42 0x000ade2f in XRE_main (argc=1, argv=0xbffff204, aAppData=0x80eac0) at ../../../toolkit/xre/nsAppRunner.cpp:3369
#43 0x000027db in main (argc=1, argv=0xbffff204) at ../../../browser/app/nsBrowserApp.cpp:156
(gdb) up
#1  0x003d44d4 in TreeInfo::nGlobalTypes (this=0x8) at jstracer.h:467
467	        return typeMap.length() - nStackTypes;
(gdb) up
#2  0x003b7701 in specializeTreesToMissingGlobals (cx=0x13e8600, globalObj=0x16fd9200, root=0x86afe0) at ../../../js/src/jstracer.cpp:1558
1558	        if (ti && ti->nGlobalTypes() < ti->globalSlots->length())
(gdb) p ti
$1 = (TreeInfo *) 0x8
(gdb) up
#3  0x003d220c in TraceRecorder::findNestedCompatiblePeer (this=0x868f60, f=0x86dc30) at ../../../js/src/jstracer.cpp:5004
5004	            specializeTreesToMissingGlobals(cx, globalObj, ti);
(gdb) p ti
$2 = (TreeInfo *) 0x86afe0
(gdb) down
#2  0x003b7701 in specializeTreesToMissingGlobals (cx=0x13e8600, globalObj=0x16fd9200, root=0x86afe0) at ../../../js/src/jstracer.cpp:1558
1558	        if (ti && ti->nGlobalTypes() < ti->globalSlots->length())
(gdb) list
1553	    JS_ASSERT(ti->globalSlots->length() == ti->typeMap.length() - ti->nStackTypes);
1554	
1555	    for (unsigned i = 0; i < root->dependentTrees.length(); i++) {
1556	        ti = (TreeInfo*)root->dependentTrees[i]->vmprivate;
1557	        /* ti can be NULL if we hit the recording tree in emitTreeCall; this is harmless. */
1558	        if (ti && ti->nGlobalTypes() < ti->globalSlots->length())
1559	            specializeTreesToMissingGlobals(cx, globalObj, ti);
1560	    }
1561	    for (unsigned i = 0; i < root->linkedTrees.length(); i++) {
1562	        ti = (TreeInfo*)root->linkedTrees[i]->vmprivate;
(gdb) p root->dependentTrees.length()
$3 = 1
(gdb) p root->dependentTrees[i]
$4 = (class nanojit::Fragment * const&) @0x1c4ab850: 0x864ec0
(gdb) p *root->dependentTrees[i]
$5 = {
  <MMgc::GCFinalizedObject> = {
    <MMgc::GCObject> = {<No data fields>}, <No data fields>}, 
  members of nanojit::Fragment: 
  _called = 424618216, 
  _native = 0, 
  _exitNative = 510426800, 
  _lir = 8839299, 
  _lirbytes = 1, 
  _token = 0x1e764c2c "?N?", 
  traceTicks = 1825452403223210208, 
  interpTicks = 1823723481309642760, 
  eot_target = 0x0, 
  sid = 0, 
  compileNbr = 424618216, 
  treeBranches = 0x0, 
  branches = 0x1e6c7eb0, 
  nextbranch = 0x869ac3, 
  anchor = 0x1, 
  root = 0x1e763594, 
  parent = 0x80a8e0, 
  first = 0x19554f4a, 
  peer = 0x8, 
  lirbuf = 0x194f2ad8, 
  lastIns = 0x0, 
  spawnedFrom = 0x0, 
  kind = 424618216, 
  ip = 0x0, 
  guardCount = 510426800, 
  xjumpCount = 8821315, 
  recordAttempts = 1, 
  blacklistLevel = 511063468, 
  fragEntry = 0x80a8e0 "\t", 
  loopEntry = 0x19554f4a "\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 !\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~??????????????????????????????????????????????????????????????????????????????????"..., 
  vmprivate = 0x8, 
  _code = 0x194f2ad8 "?Z?\030?Z?\030?Z?\030?[?\030?Z?\030\004[?\030\016[?\030?T?\030?T?\030JU?\030nU?\030?U?\030?U?\030?U?\030?V?\030?U?\030\\V?\030?V?\0300V?\030\002U?\030?W?\030JW?\030bW?\030?V?\030\002W?\030&W?\030?T?\030&U?\030?W?\030?W?\030\bX?\030,X?\030^X?\030?X?\030?X?\030?X?\030\fY?\030", 
  _links = 0x0, 
  _hits = 3, 
  _pages = 0x194f28e8
}
(gdb) p $.vmprivate
$6 = (void *) 0x8
(gdb)

Comment 26

[Andreas Gal :gal]

A reduction of the JS in #25 would be very useful. Thanks.

Comment 27

[u348128]

For reduction you first need a stable set of files. I tried to do that in #21, but I am still missing some files. And it only crashes after some reloads. A direct crash would be better.

Some of the .js files are generated and contain the solar data.

Currently, our test case is dependent of the weather. :-)

Comment 28

[Andreas Gal :gal]

#25 crashes for me every time. This looks like a really bad bug. I will work on it with dvander tomorrow.

Comment 29

[u348128]

The solar site crashes dependent on the solar data. So, sometimes it crashes consistently and sometimes it doesn't crash at all.

As I said, the crash is dependent on the weather.

By the way, what is wrong with the test cases already reduced?

Comment 30

[pourlp]

My test case and so the fully reduced test case was created from this page : http://www.solarlog-home.de/rosenhammer/visu.html

I've chosen this page because it crash firefox all the time.

I think the problem should be resolved for http://www.solarlog-home.de/rosenhammer/visu.html if it's resolved for the fully reduced test case. Don't worry ;)

With config : javascript.options.jit.content;false It does not crash

Comment 31

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to comment #26)
> A reduction of the JS in #25 would be very useful. Thanks.

gal: see comment #19 and see if the reduced testcase there is what you need.

Comment 32

[Andreas Gal :gal]

The testcase isn't right (testcase doesn't cause a crash, but the URL did). The bug is still there, and I can't reproduce it today.

We need more URLs from our top crashes, and a reduced test case.

Comment 33

[Andreas Gal :gal]

I can't reproduce today with 1.9.1 or TM tip, with any of the links or test cases. Need more urls to proceed.

Comment 34

[Aaron Train [:aaronmt]]

(In reply to comment #32)
> The testcase isn't right (testcase doesn't cause a crash, but the URL did). The
> bug is still there, and I can't reproduce it today.
> 
> We need more URLs from our top crashes, and a reduced test case.

Gal,

On clicking the attachment in comment #19, I get a crash on 3.5.1 on OSX as well a two day old clobber build of 1.9.1.1 on Windows :
 
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1 with report:

http://crash-stats.mozilla.com/report/index/74ec31be-eff4-4092-997f-7f2a92090717?p=1

and

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1pre) Gecko/20090715 Shiretoko/3.5.1pre (.NET CLR 3.5.30729)

and 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729) with report:

http://crash-stats.mozilla.com/report/index/59393c76-0a09-49bb-8343-d70c82090717?p=1 (which is actually a different signature)

So the test-case in comment #19 is still valid. Other URL's would also be ideal.

Comment 35

[Andreas Gal :gal]

Sorry, I can't reproduce with 1.9.1.1 build on mac (or tm tip). Both are debug builds with asserts enabled. I simply do not see a crash.

Comment 36

[Aaron Train [:aaronmt]]

(In reply to comment #35)
> Sorry, I can't reproduce with 1.9.1.1 build on mac (or tm tip). Both are debug
> builds with asserts enabled. I simply do not see a crash.

3.5.1 on Windows and click of attachment on comment #19

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1 (.NET CLR 3.5.30729)

http://crash-stats.mozilla.com/report/index/e0556841-762e-45ba-a42d-409b02090717?p=1

Different signature

Comment 37

[Aaron Train [:aaronmt]]

Crash on latest 1.9.1.1 with OSX this time again with test case in comment #19

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1pre) Gecko/20090717 Shiretoko/3.5.1pre

Comment 38

[Andreas Gal :gal]

I am doing an opt-build for macosx and I am installing windows to try it there.

Comment 39

[David Anderson [:dvander] - inactive, e-mail if emergency]

Tried Windows on 3.5.1 rel build. Nothing. Am trying Linux now.

Comment 40

[Aaron Train [:aaronmt]]

(In reply to comment #39)
> Tried Windows on 3.5.1 rel build. Nothing. Am trying Linux now.
Can you also try to reload the page (holding ctrl/cmd-r) see if you get any difference (i.e., eventual crash) ?

Comment 41

[David Anderson [:dvander] - inactive, e-mail if emergency]

(In reply to comment #40)

This did the trick. Andreas got it on his machine. We're looking into it.

Comment 42

[David Anderson [:dvander] - inactive, e-mail if emergency]

The bug is that tree relationships were only being treated as one-way, and thus the dependency graph for trees had dangling pointers. This has been the case since day 1 (I think). Although I added a "linkedTrees" for the reverse relationship back in February or so, it was added specifically for specializeToMissingGlobals and wasn't intended to solve the problem this bug encountered.

However, linkedTrees is only being used for the reverse relationship, so it seems fine to have js_TrashTrees walk it. Patching this locally fixes the bug. I'm running SunSpider and if it looks good, will post the patch for review.

Comment 43

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: proposed fix against 1.9.1.1

Comment 44

[Andreas Gal :gal]

Comment on attachment 389258 [details] [diff] [review]
proposed fix against 1.9.1.1

++Aaron (again!) for not giving up on this.

Comment 45

[Andreas Gal :gal]

This is a free memory read.

Probably hard to exploit, but lets not bet on it.

This is a must-have for 1.9.1.2.

Comment 46

[Andreas Gal :gal]

Can we please land this on m-c as soon it has cycled on TM? This needs baking.

Comment 47

[Mike Shaver (:shaver emeritus)]

Aye.

Comment 48

[Aaron Train [:aaronmt]]

Thanks Andreas,

Good work with the analysis.

I'm curious as to why a reload is required that instigates the crash?

Comment 49

[Andreas Gal :gal]

Every time a global script was purged, if it used a nested tree that was shared by another method, the shared tree would get deleted, but the other script would retain a reference to it and would occasionally read from that freed memory location. The fatality of this depends on whether that memory get recycled. Sometimes you get lucky and its still intact and you don't see a crash. You are more likely to fall on your face once someone mallocs that memory and starts to overwrite it. This might potentially explain some of the heap corruption top crashes we have. m-c baking should tell whether this removes some other top crashes along with it.

Comment 50

[Jesse Ruderman]

> The fatality of this depends on whether that memory get recycled.

So Valgrind, or maybe even MallocScribble, would make it happen on the first try?

Comment 51

[David Anderson [:dvander] - inactive, e-mail if emergency]

We both tried Valgrind - Andreas had the OS X version and I'm not sure what happened there (I think he said valgrind itself crashed). I tried it on Linux and Fx crashed on the first try, but it almost always crashed on the first try on Linux anyway. Boo-urns to me for not trying Linux _or_ valgrind sooner.

Comment 52

[Andreas Gal :gal]

I was able to see it happen in valgrind on macosx, so yes, valgrind definitively would have revealed this (we tried it fairly late in the process though, at that time we already suspected a use-after-free).

Comment 53

[Robert Sayre]

(In reply to comment #46)
> Can we please land this on m-c as soon it has cycled on TM? This needs baking.

It hasn't gotten a good cycle on TM yet, I think due to infra issues. monitoring.

Comment 54

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/cfebb17bf8c0

Comment 55

[Samuel Sidler (old account; do not CC)]

Comment on attachment 389258 [details] [diff] [review]
proposed fix against 1.9.1.1

Approved for 1.9.1.2. a=ss for release-drivers

Comment 56

[Robert Sayre]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/d9b2e1cf2765

Comment 57

[Bob Clary [:bc] (inactive)]

(In reply to comment #34)

I was able to reproduce a crash on http://www.solarlog-home.de/rosenhammer/visu.html several times on Firefox 3.5.2/1.9.1.2 Windows but the crash isn't 100% reproducible. I couldn't crash on mac.

bp-13526b6c-401b-47b0-9215-56c362090730

js3250.dll@0x68a94  	
js3250.dll 	js_FindVMCompatiblePeer 	js/src/jstracer.cpp:4448

Comment 58

[Aaron Train [:aaronmt]]

(In reply to comment #57)
> (In reply to comment #34)
> 
> I was able to reproduce a crash on
> http://www.solarlog-home.de/rosenhammer/visu.html several times on Firefox
> 3.5.2/1.9.1.2 Windows but the crash isn't 100% reproducible. I couldn't crash
> on mac.
> 
> bp-13526b6c-401b-47b0-9215-56c362090730
> 
> js3250.dll@0x68a94      
> js3250.dll     js_FindVMCompatiblePeer     js/src/jstracer.cpp:4448

Because that site is always changing data I could not reproduce on Windows nor Mac with 3.5.2/1.9.1.2 nor the attachment in comment #19

Could you crash on the attachment?

Comment 59

[Bob Clary [:bc] (inactive)]

No.

Comment 60

[juan becerra [:juanb]]

On 3.5 on Windows, I could crash reliably using the reduced test case, but not at all using the URL on comment #0.

On 3.5.2 I could not crash on either.

However, I noticed that Bob's crash on the URL using 3.5.2 has a very similar crash thread as the one I got when I tried the reduced test case on 3.5:  

333e04c4-c1e3-48d0-a295-c1e282090730

David, Andreas could you take a look to see what we fixed here?

Comment 61

[u348128]

Could you reproduce with #21? Hit the reload button several times.

Lucas

Comment 62

[u279076]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

I attempted to reproduce this by reloading the page in comment 21 fast (before page load) and slow (after page load) several times (at least 20).  I cannot reproduce this on any platform.

Verified1.9.1?

Comment 63

[juan becerra [:juanb]]

This morning I have been clicking away at url in comment #21, and I was able to crash consistently on 3.5.1 (Mac) after several reloads (~20). However, I crash on 3.5.2, although it took more than 60 reloads, sometimes more (up to 100 reloads), sometimes less, depending on how fast I reloaded the page.

http://crash-stats.mozilla.com/report/index/3d0ccfad-e4d1-4217-a20a-453d02090801

Andreas, David, could you take a look before I re-open this?

Comment 64

[u279076]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

I reloaded the page 200 times -- no crash.  Juan, are you using the same profile in 3.5.2 that crashed in 3.5.1?  In my case, I just used a clean profile on 3.5.2.

Comment 65

[Andreas Gal :gal]

Can we verify that the fix is in the build juan used?

Comment 66

[Andreas Gal :gal]

#64: a bad profile isn't allowed to cause such a crash, so if thats the case, we still would have to investigate.

Comment 67

[juan becerra [:juanb]]

I have used different 3.5.2 locales, for example fr, on fresh profiles, as well as a 3.5.1->3.5.2 updated build.

Comment 68

[juan becerra [:juanb]]

I should add that I after a while, I would not let the page load fully but I would just press command-r to reload.

Comment 69

[Nick Thomas [:nthomas] (UTC+12)]

(In reply to comment #65)
> Can we verify that the fix is in the build juan used?

about:buildconfig will say the builds are from rev b8dbd5ab1647. Looks like the patch is there:
http://hg.mozilla.org/releases/mozilla-1.9.1/file/b8dbd5ab1647/js/src/jstracer.cpp#l3625

Comment 70

[Andreas Gal :gal]

Juan, are you local in MV? If so it would be great if you can show me how to reproduce this. I am still not having any luck. I am using a custom built 1.9.1 macosx executable now (debug build).

Comment 71

[Henrik Skupin [:whimboo][⌚️UTC+1][away 07/22 - 07/26]]

Andreas, could we create a new bug for the remaining work as it was given as proposal on releasedrivers?

Comment 72

[Andreas Gal :gal]

#71: new bug filed as bug 507901

Comment 73

[Tobias (:Tobbi) Markus]

(In reply to comment #72)
> #71: new bug filed as bug 507901

Andreas, can you CC me, please?

Comment 74

[Andreas Gal :gal]

(The other bug is closed, too. Please email me if you can't add yourself and want to be added.)

Comment 75

[Samuel Sidler (old account; do not CC)]

This bug should remain closed until bug 507901 is resolved.

Comment 76

[Mike Beltzner [:beltzner, not reading bugmail]]

Mass change: adding fixed1.9.2 keyword

(This bug was identified as a mozilla1.9.2 blocker which was fixed before the mozilla-1.9.2 repository was branched (August 13th, 2009) as per this query: http://is.gd/2ydcb - if this bug is not actually fixed on mozilla1.9.2, please remove the keyword. Apologies for the bugspam)

Comment 77

[Christian Holler (:decoder)]

Filter on qa-project-auto-change:

Bug in removed tracer code, setting in-testsuite- flag.