Closed Bug 503144 Opened 12 years ago Closed 11 years ago

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

Categories

(Core :: JavaScript Engine, defect)

1.9.1 Branch
defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
status1.9.2 --- beta1-fixed
blocking1.9.1 --- .2+
status1.9.1 --- .2-fixed

People

(Reporter: Tobbi, Assigned: dvander)

References

Details

(Keywords: common-issue+, crash, testcase, Whiteboard: [sg:critical?] keep bug closed until bug 507901 is fixed)

Crash Data

Attachments

(5 files)

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.
Flags: blocking1.9.2?
In Linux, the same testcase crashed with bp-28309a1f-62ec-41bc-9a0b-d75812090708
Summary: Crash in [@ js3250.dll@0x68bec] visiting certain pages → Crash in [@ js3250.dll@0x68bec] [@ specializeTreesToMissingGlobals(JSContext*, TreeInfo*) ] visiting certain pages
OS: Windows Vista → All
Hardware: x86 → All
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
Is not consistently to reproduce here on Vista. Four times in a row but then it stopped.
Keywords: testcase
testcase keyword is used to indicate an attached or inline test independent of the original crashing page.
Keywords: common-issue+
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
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.
Keywords: qawanted
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/
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.
(In reply to comment #8)
I can reproduce this in 3.5 w/ OS X. Investigating
pourlp, this bug wouldn't happen in safe mode because safe mode disables the JIT (see bug 453642 and bug 478846).
Flags: blocking1.9.2?
Flags: blocking1.9.2+
Flags: blocking1.9.1.1?
dangit, now i can't repro
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
The site: http://www.autotitre.com/

also uses the escape function.
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.
(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");
}
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.
Stacks show that there are scary addresses, so turning security-sensitive just to be safe.
Version: unspecified → 1.9.1 Branch
Group: core-security
Keywords: crash, testcase
Attached file 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)
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.
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.
Assignee: general → dvander
(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.
blocking1.9.1: --- → needed
Flags: blocking1.9.1.1? → blocking1.9.1.1-
Attached file 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).
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
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)
A reduction of the JS in #25 would be very useful. Thanks.
Keywords: qawanted
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. :-)
#25 crashes for me every time. This looks like a really bad bug. I will work on it with dvander tomorrow.
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?
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
(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.
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.
Keywords: testcase
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.
(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.
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.
(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
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
I am doing an opt-build for macosx and I am installing windows to try it there.
Tried Windows on 3.5.1 rel build. Nothing. Am trying Linux now.
(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) ?
(In reply to comment #40)

This did the trick. Andreas got it on his machine. We're looking into it.
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.
Attachment #389258 - Attachment description: proposed fix → proposed fix against 1.9.1.1
Comment on attachment 389258 [details] [diff] [review]
proposed fix against 1.9.1.1

++Aaron (again!) for not giving up on this.
Attachment #389258 - Flags: review?(gal) → review+
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.
blocking1.9.1: needed → ?
Whiteboard: [sg:critical?]
Can we please land this on m-c as soon it has cycled on TM? This needs baking.
Thanks Andreas,

Good work with the analysis.

I'm curious as to why a reload is required that instigates the crash?
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.
> 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?
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.
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).
(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.
http://hg.mozilla.org/mozilla-central/rev/cfebb17bf8c0
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
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
Attachment #389258 - Flags: approval1.9.1.2? → approval1.9.1.2+
(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
(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?
No.
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?
Could you reproduce with #21? Hit the reload button several times.

Lucas
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?
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?
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.
Can we verify that the fix is in the build juan used?
#64: a bad profile isn't allowed to cause such a crash, so if thats the case, we still would have to investigate.
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.
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.
(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
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).
Andreas, could we create a new bug for the remaining work as it was given as proposal on releasedrivers?
#71: new bug filed as bug 507901
Keywords: qawanted
(In reply to comment #72)
> #71: new bug filed as bug 507901

Andreas, can you CC me, please?
(The other bug is closed, too. Please email me if you can't add yourself and want to be added.)
Flags: wanted1.9.0.x-
This bug should remain closed until bug 507901 is resolved.
Group: core-security
Keywords: testcase
Group: core-security
Blocks: 507901
Whiteboard: [sg:critical?] → [sg:critical?] keep bug closed until bug 507901 is fixed
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)
Keywords: fixed1.9.2
Group: core-security
Crash Signature: [@ js3250.dll@0x68bec] [@ specializeTreesToMissingGlobals(JSContext*, TreeInfo*) ]
Filter on qa-project-auto-change:

Bug in removed tracer code, setting in-testsuite- flag.
Flags: in-testsuite-
You need to log in before you can comment on or make changes to this bug.