456810 - TM: Crash on digg.com with adblock plus [@ ReconstructPCStack]

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect, P1)

Description

[Brian Polidoro]

STR:
1 in a new profile install adblock plus
2 enable content jit
3 goto digg.com

bp-edc2813d-89a6-11dd-9db4-001a4bd43ef6

The stack doesn't look like the other recent js_Interpret bugs.  This started with the latest TM merge.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Same crash happens under OS X. Here the complete stack trace from my debugger. It looks like that breakpad doesn't fetch everything. There are some more frames above js_Interpret:

#0  JS_Assert (s=0x35b510 "script->main <= target && target < script->code + script->length", file=0x35b060 "/Volumes/Daten/mozilla/source/mozilla/js/src/jsopcode.cpp", ln=5183) at /Volumes/Daten/mozilla/source/mozilla/js/src/jsutil.cpp:63
#1  0x002873cd in ReconstructPCStack (cx=0xb84e00, script=0x17d8fd50, target=0x1e00005a "1?\262\2431?\262\2431?\261\a1?\261\a1?\261\a1?\260k0?\260k0?\260k0?\260\320/?\260\320/?\260\320/?\2574/?\2574/?\2574/?\257\230.?\257\230.?\257\230.?\256\375-?\256\375-?\256\375-?\255a-?\255a-?\255a-?\255\306,?\255\306,?\255\306,?\254*,?\254*,?\254*,?\254\216+?\254\216+?\254\216+?\253\363*?\253\363*?\253\363*?\252W*?\252W*?\252W*?\252\274)?\252\274)?\252\274)?\251 )?\251 )?\251 )?\251\204(?\251\204(?\251\204(?\250\351'?\250\351'?\250\351"..., pcstack=0x0) at /Volumes/Daten/mozilla/source/mozilla/js/src/jsopcode.cpp:5183
#2  0x00297459 in js_ReconstructStackDepth (cx=0xb84e00, script=0x17d8fd50, pc=0x1e00005a "1?\262\2431?\262\2431?\261\a1?\261\a1?\261\a1?\260k0?\260k0?\260k0?\260\320/?\260\320/?\260\320/?\2574/?\2574/?\2574/?\257\230.?\257\230.?\257\230.?\256\375-?\256\375-?\256\375-?\255a-?\255a-?\255a-?\255\306,?\255\306,?\255\306,?\254*,?\254*,?\254*,?\254\216+?\254\216+?\254\216+?\253\363*?\253\363*?\253\363*?\252W*?\252W*?\252W*?\252\274)?\252\274)?\252\274)?\251 )?\251 )?\251 )?\251\204(?\251\204(?\251\204(?\250\351'?\250\351'?\250\351"...) at /Volumes/Daten/mozilla/source/mozilla/js/src/jsopcode.cpp:5159
#3  0x002ff576 in js_ExecuteTree (cx=0xb84e00, treep=0xbfffbb28, inlineCallCount=@0xbfffc6a0, innermostNestedGuardp=0xbfffbb24) at /Volumes/Daten/mozilla/source/mozilla/js/src/jstracer.cpp:2531
#4  0x0030512a in js_MonitorLoopEdge (cx=0xb84e00, oldpc=0x17d8fdf6 "\b\377\353T", inlineCallCount=@0xbfffc6a0) at /Volumes/Daten/mozilla/source/mozilla/js/src/jstracer.cpp:2628
#5  0x00232a4a in js_Interpret (cx=0xb84e00) at /Volumes/Daten/mozilla/source/mozilla/js/src/jsinterp.cpp:3065
#6  0x00269140 in js_Execute (cx=0xb84e00, chain=0x1a502120, script=0x19279eb0, down=0x0, flags=0, result=0x0) at jsinterp.cpp:1550
#7  0x001e707c in JS_EvaluateUCScriptForPrincipals (cx=0xb84e00, obj=0x1a502120, principals=0x1d531f14, chars=0xbfffd448, length=14, filename=0x1d770418 "http://digg.com/", lineno=585, rval=0x0) at /Volumes/Daten/mozilla/source/mozilla/js/src/jsapi.cpp:5016
#8  0x130c6e7f in nsJSContext::EvaluateString (this=0x1dec6e80, aScript=@0xbfffd434, aScopeObject=0x1a502120, aPrincipal=0x1d531f10, aURL=0x1d770418 "http://digg.com/", aLineNo=585, aVersion=0, aRetValue=0x0, aIsUndefined=0xbfffd3b8) at /Volumes/Daten/mozilla/source/mozilla/dom/src/base/nsJSEnvironment.cpp:1574
#9  0x12eb9df4 in nsScriptLoader::EvaluateScript (this=0x1d6e1930, aRequest=0x19279e80, aScript=@0xbfffd434) at /Volumes/Daten/mozilla/source/mozilla/content/base/src/nsScriptLoader.cpp:594
#10 0x12eba1c4 in nsScriptLoader::ProcessRequest (this=0x1d6e1930, aRequest=0x19279e80) at /Volumes/Daten/mozilla/source/mozilla/content/base/src/nsScriptLoader.cpp:504
#11 0x12ebb95c in nsScriptLoader::ProcessScriptElement (this=0x1d6e1930, aElement=0x1849ee90) at /Volumes/Daten/mozilla/source/mozilla/content/base/src/nsScriptLoader.cpp:458
#12 0x12eb7668 in nsScriptElement::MaybeProcessScript (this=0x1849ee90) at /Volumes/Daten/mozilla/source/mozilla/content/base/src/nsScriptElement.cpp:188
#13 0x12f7e65d in nsHTMLScriptElement::MaybeProcessScript (this=0x1849ee70) at /Volumes/Daten/mozilla/source/mozilla/content/html/content/src/nsHTMLScriptElement.cpp:547
#14 0x12f7d7ed in nsHTMLScriptElement::DoneAddingChildren (this=0x1849ee70, aHaveNotified=1) at /Volumes/Daten/mozilla/source/mozilla/content/html/content/src/nsHTMLScriptElement.cpp:484
#15 0x12fab4f1 in HTMLContentSink::ProcessSCRIPTEndTag (this=0xc6cc00, content=0x1849ee70, aMalformed=0) at /Volumes/Daten/mozilla/source/mozilla/content/html/document/src/nsHTMLContentSink.cpp:3141
#16 0x12facc57 in SinkContext::CloseContainer (this=0x1c5380e0, aTag=eHTMLTag_script, aMalformed=0) at /Volumes/Daten/mozilla/source/mozilla/content/html/document/src/nsHTMLContentSink.cpp:1012
#17 0x12fad115 in HTMLContentSink::CloseContainer (this=0xc6cc00, aTag=eHTMLTag_script) at /Volumes/Daten/mozilla/source/mozilla/content/html/document/src/nsHTMLContentSink.cpp:2387
#18 0x1b9164b9 in CNavDTD::CloseContainer (this=0x1d627320, aTag=eHTMLTag_script, aMalformed=0) at /Volumes/Daten/mozilla/source/mozilla/parser/htmlparser/src/CNavDTD.cpp:2780
#19 0x1b9186b0 in CNavDTD::HandleEndToken (this=0x1d627320, aToken=0x24295020) at /Volumes/Daten/mozilla/source/mozilla/parser/htmlparser/src/CNavDTD.cpp:1683
#20 0x1b91b894 in CNavDTD::HandleToken (this=0x1d627320, aToken=0x24295020, aParser=0x1b8b7080) at /Volumes/Daten/mozilla/source/mozilla/parser/htmlparser/src/CNavDTD.cpp:764
#21 0x1b914ccd in CNavDTD::BuildModel (this=0x1d627320, aParser=0x1b8b7080, aTokenizer=0x1c504f30, anObserver=0x0, aSink=0xc6cc90) at /Volumes/Daten/mozilla/source/mozilla/parser/htmlparser/src/CNavDTD.cpp:336
#22 0x1b926c17 in nsParser::BuildModel (this=0x1b8b7080) at /Volumes/Daten/mozilla/source/mozilla/parser/htmlparser/src/nsParser.cpp:1779
#23 0x1b92a3e8 in nsParser::ResumeParse (this=0x1b8b7080, allowIteration=1, aIsFinalChunk=1, aCanInterrupt=1) at /Volumes/Daten/mozilla/source/mozilla/parser/htmlparser/src/nsParser.cpp:1656
#24 0x1b92acae in nsParser::ContinueInterruptedParsing (this=0x1b8b7080) at /Volumes/Daten/mozilla/source/mozilla/parser/htmlparser/src/nsParser.cpp:1174
#25 0x12e14712 in nsContentSink::ContinueInterruptedParsingIfEnabled (this=0xc6cc00) at /Volumes/Daten/mozilla/source/mozilla/content/base/src/nsContentSink.cpp:1750
#26 0x12e1bf40 in nsRunnableMethod<nsContentSink>::Run (this=0x175287b0) at nsThreadUtils.h:264
#27 0x0047a862 in nsThread::ProcessNextEvent (this=0x715000, mayWait=0, result=0xbfffe014) at /Volumes/Daten/mozilla/source/mozilla/xpcom/threads/nsThread.cpp:510
#28 0x004049de in NS_ProcessPendingEvents_P (thread=0x715000, timeout=20) at nsThreadUtils.cpp:180
#29 0x11884ea7 in nsBaseAppShell::NativeEventCallback (this=0x74bb20) at /Volumes/Daten/mozilla/source/mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:121
#30 0x1183ea02 in nsAppShell::ProcessGeckoEvents (aInfo=0x74bb20) at /Volumes/Daten/mozilla/source/mozilla/widget/src/cocoa/nsAppShell.mm:302
#31 0x96927615 in CFRunLoopRunSpecific ()
#32 0x96927cf8 in CFRunLoopRunInMode ()
#33 0x93c33480 in RunCurrentEventLoopInMode ()
#34 0x93c33299 in ReceiveNextEventCommon ()
#35 0x93c3310d in BlockUntilNextEventMatchingListInMode ()
#36 0x905803ed in _DPSNextEvent ()
#37 0x9057fca0 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#38 0x90578cdb in -[NSApplication run] ()
#39 0x1183d3b8 in nsAppShell::Run (this=0x74bb20) at /Volumes/Daten/mozilla/source/mozilla/widget/src/cocoa/nsAppShell.mm:591
#40 0x12533ee2 in nsAppStartup::Run (this=0x7665e0) at /Volumes/Daten/mozilla/source/mozilla/toolkit/components/startup/src/nsAppStartup.cpp:182
#41 0x000f5d5f in XRE_main (argc=3, argv=0xbffff65c, aAppData=0x70eb10) at /Volumes/Daten/mozilla/source/mozilla/toolkit/xre/nsAppRunner.cpp:3220
#42 0x000026e3 in main (argc=3, argv=0xbffff65c) at /Volumes/Daten/mozilla/source/mozilla/browser/app/nsBrowserApp.cpp:156

Comment 2

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

I can't reproduce the same stack but I do get a crash -- working on a fix.

Comment 3

[Brendan Eich [:brendan]]

I'll help, we need to get this for b1.

/be

Comment 4

[Andreas Gal :gal]

Attachment: patch

Comment 5

[Brendan Eich [:brendan]]

Two

Comment 6

[Brendan Eich [:brendan]]

Andreas kindly handed off to me. We believe that

1. Guarding on shape in GETELEM and SETELEM is enough to handle global object aliasing too, if the recorder verifies that the global shape does not match the recording-time object's shape. This is because two objects have the same shape if and only if either (a) they have the same scope (one is an unmutated proto-child of another); (b) they have had the same properties added in the same order.

1(a) means a global shape check will abort GET/SETELEM tracing of an unmutated proto-child of the global object, but this is necessary:

  var o = {__proto__:this}

at top level would make such an object, and we cannot yet handle aliased o.x references to an imported global variable named x.

2(b) is unlikely and again would lead only sub-optimal aborts for GET/SETELEM on any object having the same shape as (but no prototype relation to) the global object. If we find this to be a problem we can use SCOPE_MAKE_UNIQUE_SHAPE on the global object before starting a recording, although this will effectively purge the property cache for all global props indexed by traced bytecode addresses.

Let's optimize by simply aborting if GET/SETELEM happens on an object whose shape matches the global shape.

2. The recorder also must verify either (a) that the named property does not exit; or (b) it exists but has no scripted getter or setter. We would need some trampoline mechanism to run scripted getters and setters in their caller's frame (see bug 456511). Until then, we must abort on such scripted hooks.

This means looking up the property at recording time, not using the property cache (since the interpreter does not use the cache for GET/SETELEM).

/be

Comment 7

[Brendan Eich [:brendan]]

Attachment: proposed fix

Also I restored |obj| as the canonical name of JSObject*-typed variables, using lval for the left or left-most operand of the elem op. This saves some tedious JSVAL_TO_OBJECT calls and makes result set()s look better (they are not setting "obj" in any sense, rather the result value of the get or set elem op).

Testing now.

/be

Comment 8

[Brendan Eich [:brendan]]

Tests well for me. Committing to tm:

http://hg.mozilla.org/tracemonkey/rev/308e7e1eb1cf

/be

Comment 10

[Jo Hermans]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080926033937 Minefield/3.1b1pre

When testing bug 457391, I encountered crash dump 6f2d05e6-8c7f-11dd-94f1-001cc45a2c28, which is exactly the same as comment 1. That was with today's version, which has the patch from comment 8.

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Jo, you have to use a tracemonkey build to test the fix. It's on a separate branch and will not be included in normal nightly builds yet. Please try again with following build:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008/09/2008-09-27-03-tracemonkey/

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Brendan, when the next sync with central will be happen? Is there a date set right now?

Comment 13

[John Wong]

Please include the patch to normal nightly build.
It fixed the problem (digg.com crash)
Thank you all.

Comment 14

[Brendan Eich [:brendan]]

Fixed on m-c:

http://hg.mozilla.org/mozilla-central/rev/308e7e1eb1cf

/be

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Verified fixed with the following builds:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20081002
Minefield/3.1b1pre ID:20081002033404

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre)
Gecko/20081002 Minefield/3.1b1pre ID:20081002020319