454343 - Assertion failure: obj == pobj, at src/js/src/jsinterp.cpp:160

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Bobby Holley (:bholley)]

Keith was complaining about this bug last week - we figured it was his system but I just ran into the same thing when I tried to run the mochitest he was having trouble with.

Reproducible: Always

Steps to reproduce:
Fire up mochitests
run the xpconnect tests - should fail on the last one.

Backtrace:

Process:         firefox-bin [61432]
Path:            /files/mozilla/obj/dist/MinefieldDebug.app/Contents/MacOS/firefox-bin
Identifier:      org.mozilla.firefox
Version:         3.1b1pre (3.1b1pre)
Code Type:       X86 (Native)
Parent Process:  Python [61426]

Date/Time:       2008-09-08 20:12:22.359 -0700
OS Version:      Mac OS X 10.5.2 (9C7010)
Report Version:  6

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Crashed Thread:  0

Thread 0 Crashed:
0   libmozjs.dylib                	0x002cc771 JS_Assert + 67 (jsutil.cpp:63)
1   libmozjs.dylib                	0x00264e1c js_FillPropertyCache + 302 (jsinterp.cpp:161)
2   libmozjs.dylib                	0x0027d364 js_FindPropertyHelper + 360 (jsobj.cpp:3513)
3   libmozjs.dylib                	0x00244cd0 js_Interpret + 91364 (jsinterp.cpp:5084)
4   libmozjs.dylib                	0x0026711f js_Execute + 813 (jsinterp.cpp:1553)
5   libmozjs.dylib                	0x001e57a6 JS_EvaluateUCScriptForPrincipals + 312 (jsapi.cpp:5019)
6   libgklayout.dylib             	0x11f3fbf7 nsJSContext::EvaluateString(nsAString_internal const&, void*, nsIPrincipal*, char const*, unsigned int, unsigned int, nsAString_internal*, int*) + 977 (nsJSEnvironment.cpp:1572)
7   libgklayout.dylib             	0x11d34808 nsScriptLoader::EvaluateScript(nsScriptLoadRequest*, nsString const&) + 952 (nsScriptLoader.cpp:594)
8   libgklayout.dylib             	0x11d34bd8 nsScriptLoader::ProcessRequest(nsScriptLoadRequest*) + 328 (nsScriptLoader.cpp:504)
9   libgklayout.dylib             	0x11d34c64 nsScriptLoader::ProcessPendingRequests() + 74 (nsScriptLoader.cpp:643)
10  libgklayout.dylib             	0x11d37c6c nsRunnableMethod<nsScriptLoader>::Run() + 102 (nsThreadUtils.h:265)
11  libxpcom_core.dylib           	0x004cda40 nsThread::ProcessNextEvent(int, int*) + 676 (nsThread.cpp:511)
12  libxpcom_core.dylib           	0x00457a2e NS_ProcessPendingEvents_P(nsIThread*, unsigned int) + 146 (nsThreadUtils.cpp:180)
13  libwidget_mac.dylib           	0x145356b9 nsBaseAppShell::NativeEventCallback() + 181 (nsBaseAppShell.cpp:122)
14  libwidget_mac.dylib           	0x144f033e nsAppShell::ProcessGeckoEvents(void*) + 518 (nsAppShell.mm:303)
15  com.apple.CoreFoundation      	0x9578562e CFRunLoopRunSpecific + 3166
16  com.apple.CoreFoundation      	0x95785d18 CFRunLoopRunInMode + 88
17  com.apple.HIToolbox           	0x93c6e6a0 RunCurrentEventLoopInMode + 283
18  com.apple.HIToolbox           	0x93c6e4b9 ReceiveNextEventCommon + 374
19  com.apple.HIToolbox           	0x93c6e32d BlockUntilNextEventMatchingListInMode + 106
20  com.apple.AppKit              	0x94d587d9 _DPSNextEvent + 657
21  com.apple.AppKit              	0x94d5808e -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
22  com.apple.AppKit              	0x94d510c5 -[NSApplication run] + 795
23  libwidget_mac.dylib           	0x144eecf4 nsAppShell::Run() + 288 (nsAppShell.mm:591)
24  libtoolkitcomps.dylib         	0x141e8f36 nsAppStartup::Run() + 148 (nsAppStartup.cpp:182)
25  XUL                           	0x000f4fd9 XRE_main + 13995 (nsAppRunner.cpp:3220)
26  org.mozilla.firefox           	0x0000262b main + 709 (nsBrowserApp.cpp:156)
27  org.mozilla.firefox           	0x00001c58 _start + 210
28  org.mozilla.firefox           	0x00001b85 start + 41

Comment 1

[Brendan Eich [:brendan]]

Reproducing in the latest m-c builds? If so, reduced testcase?

/be

Comment 2

[Bobby Holley (:bholley)]

Repro with 71c48ddc9e8c as my tip. If there's something later on that might fix it I can pull that and give it a shot.

Don't have time to track down the issue further at the moment. Do the xpconnect mochitests work for you?

Comment 3

[Mats Palmgren (inactive)]

Attachment: Crash stack + data

I see this in a Linux x86_64 debug build too, when running mochitests.
I ran it twice and it crashed on "test_wrappers.html" both times,
but if I run just that test it passes.

Comment 4

[Jason Orendorff [:jorendorff]]

(gdb) sele 1
(gdb) p obj
$1 = (JSObject *) 0x158d2460
(gdb) p pobj
$2 = (JSObject *) 0xcecede0
(gdb) jsclass pobj
Window at 0x155d9274
(gdb) jsclass obj
Block at 0x36d180

It happens when evaluating |location| here:

    var answer = [];
    for (let i in location)
        answer.push(i);

js_Disassemble says:

   00000:  10  defvar "answer"
   00003:  13  defvar "expected"
   00006:  65  defvar "origProto"
   main:
   00009:  10  newinit 3
   00011:  10  endinit
   00012:  10  setgvar "answer"
   00015:  10  pop
   00016:  11  enterblock depth 0 {i: 0}
-> 00019:  11  name "location"
   00022:  11  iter 1
   00024:  11  forlocal 36
   ...

Why are we emitting JSOP_NAME here rather than JSOP_GETGVAR?

Regardless of that, I don't see why scopeIndex is 0 here.

Comment 5

[Jason Orendorff [:jorendorff]]

Sorry, dumb quick stubs bug.

scopeIndex is wrong because on entering js_FindPropertyHelper, the Block hasn't been instantiated yet, so cx->fp->scopeChain points to the global object.

Then, when js_FindPropertyHelper calls js_LookupPropertyWithFlags,

- the nsWindowSH::NewResolve hook is called
- which results in creating the location object
- which results in trying to attach quick stubs to location.__proto__
- which fails because location.__proto__ is specially nonwriteable.
- In preparing to throw the exception, XPConnect calls JS_GetScopeChain
- which instantiates the let block and changing cx->fp->scopeChain out from
  under js_FindPropertyHelper.

The quick stubs machinery then ignores the exception and proceeds; the resolve hook actually succeeds, leading to the assert.  Quick fix coming.

Comment 6

[Jason Orendorff [:jorendorff]]

Attachment: fix: don't do that

Comment 7

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 338896 [details] [diff] [review]
fix: don't do that

r+sr=mrbkap

Comment 8

[Jason Orendorff [:jorendorff]]

Pushed http://hg.mozilla.org/mozilla-central/rev/31c03e2ff02d .

The symptom is RESO FIXED.

But Brendan, if the API says it's OK to call JS_GetScopeChain from a resolve hook, or otherwise call back into the interpreter, then there is still a (now-latent) bug in js_FindPropertyHelper.

Comment 9

[Brendan Eich [:brendan]]

(In reply to comment #8)
> But Brendan, if the API says it's OK to call JS_GetScopeChain from a resolve
> hook, or otherwise call back into the interpreter, then there is still a
> (now-latent) bug in js_FindPropertyHelper.

Please file it. Any reason not to?

/be

Comment 10

[Bob Clary [:bc] (inactive)]

covered by mochitests/xpconnect