Closed Bug 885697 Opened 11 years ago Closed 11 years ago

Assertion failure: obj, at \include\js/Value.h:481

Categories

(Core :: JavaScript Engine, defect)

x86
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 859609

People

(Reporter: cbook, Unassigned)

Details

(Keywords: assertion, Whiteboard: [dupe 859609?])

Loading http://www.challenges.fr/classements/fortune/ (will also try to create a testcase) results in windows debug builds in Assertion failure: obj, at c:\work\mozilla\builds\nightly\mozilla\firefox-debug\dist\include\js/Value.h:481


Thread 0 (crashed)
 0  mozjs.dll!OBJECT_TO_JSVAL_IMPL [Value.h : 481 + 0x1d]
    eip = 0x71a02523   esp = 0x0025d864   ebp = 0x0025d86c   ebx = 0x0606b018
    esi = 0x04ff46f8   edi = 0x0025db80   eax = 0x00000000   ecx = 0xf6a7f8f5
    edx = 0x7338f4d8   efl = 0x00200212
    Found by: given as instruction pointer in context
 1  mozjs.dll!JS::Value::setObject(JSObject &) [Value.h : 903 + 0x8]
    eip = 0x71a024de   esp = 0x0025d874   ebp = 0x0025d884
    Found by: call frame info
 2  mozjs.dll!JS::ObjectValue [Value.h : 1243 + 0xb]
    eip = 0x71eaf6f2   esp = 0x0025d88c   ebp = 0x0025d898
    Found by: call frame info
 3  mozjs.dll!js::ion::SnapshotIterator::FromTypedPayload(JSValueType,unsigned int) [IonFrames.cpp : 1102 + 0x8]
    eip = 0x71eaf4fa   esp = 0x0025d8a0   ebp = 0x0025d8d0
    Found by: call frame info
 4  mozjs.dll!js::ion::SnapshotIterator::slotValue(js::ion::SnapshotReader::Slot const &) [IonFrames.cpp : 1146 + 0x22]
    eip = 0x71eafbc9   esp = 0x0025d8d8   ebp = 0x0025d958
    Found by: call frame info
 5  mozjs.dll!js::ion::SnapshotIterator::read() [IonFrameIterator.h : 239 + 0x18]
    eip = 0x71a0f142   esp = 0x0025d960   ebp = 0x0025d980
    Found by: call frame info
 6  mozjs.dll!js::ion::InlineFrameIteratorMaybeGC<1>::findNextFrame() [IonFrames.cpp : 1266 + 0x11]
    eip = 0x71eb0f3f   esp = 0x0025d988   ebp = 0x0025d9c0
    Found by: call frame info
 7  mozjs.dll!js::ion::InlineFrameIteratorMaybeGC<1>::resetOn(js::ion::IonFrameIterator const *) [IonFrames.cpp : 1222 + 0xa]
    eip = 0x71eb158b   esp = 0x0025d9c8   ebp = 0x0025da54
    Found by: call frame info
 8  mozjs.dll!js::ion::InlineFrameIteratorMaybeGC<1>::InlineFrameIteratorMaybeGC<1>(JSContext *,js::ion::IonFrameIterator const *) [IonFrameIterator-inl.h : 66 + 0xb]
    eip = 0x71b4d364   esp = 0x0025da5c   ebp = 0x0025da6c
    Found by: call frame info
 9  mozjs.dll!js::ion::GetPcScript(JSContext *,JSScript * *,unsigned char * *) [IonFrames.cpp : 1019 + 0x12]
    eip = 0x71eaeefb   esp = 0x0025da74   ebp = 0x0025dbc4
    Found by: call frame info
10  mozjs.dll!js::ContextStack::currentScript(unsigned char * *,js::ContextStack::MaybeAllowCrossCompartment) [Stack-inl.h : 350 + 0x13]
    eip = 0x71a6b570   esp = 0x0025dbcc   ebp = 0x0025dbf0
    Found by: call frame info
11  mozjs.dll!GetPropertyHelperInline<1> [jsobj.cpp : 3936 + 0x1c]
    eip = 0x71c98a81   esp = 0x0025dbf8   ebp = 0x0025dcf8
    Found by: call frame info
12  mozjs.dll!js::GetPropertyHelper(JSContext *,JS::Handle<JSObject *>,JS::Handle<jsid>,unsigned int,JS::MutableHandle<JS::Value>) [jsobj.cpp : 4010 + 0x1c]
    eip = 0x71c912a0   esp = 0x0025dd00   ebp = 0x0025dd18
    Found by: call frame info
13  mozjs.dll!js::ion::GetPropertyIC::update(JSContext *,unsigned int,JS::Handle<JSObject *>,JS::MutableHandle<JS::Value>) [IonCaches.cpp : 1516 + 0x20]
    eip = 0x71e9ff2f   esp = 0x0025dd20   ebp = 0x0025de38
    Found by: call frame info
14  mozjs.dll!js::Proxy::get(JSContext *,JS::Handle<JSObject *>,JS::Handle<JSObject *>,JS::Handle<jsid>,JS::MutableHandle<JS::Value>) [jsproxy.cpp : 2480 + 0x11]
    eip = 0x71cc5db8   esp = 0x0025de94   ebp = 0x0025ddc4
    Found by: call frame info with scanning
The assertion doesn't sound too bad.  Is it bad to have JSVAL_TAG_OBJECT with a payload of null?  npb, could you maybe look at this?  It seems to involve a lot of IonMonkey.
Flags: needinfo?(nicolas.b.pierron)
This crash is likely a result of the recent changes made by Kannan:
  see Bug 885726, which has a similar stack.
  and Bug 883973 comment 29, which is highly related to this crash.
  and Bug 859609 probably caused it.

When I made findNextFrame, funval was supposed to be a constant function in order to iterate the stack.  The reason why it had to be a constant is that the snapshots are not made to be iterated over while in a call but only during bailouts.

Otherwise, as we are in the middle of a call the value contained in the register might not reference the JSFunction but something totally different.

The constant thing, was the simplest work-around for that, but another way to do it would be to either have the JSFunction be a constant or be spilled.

Before bug 859609, knowing that we were inlining a call, we could always store it as a constant, but for inlining lambdas we need to keep the scope chain and refer to the right JSFunction which has been created for the lambda.
Flags: needinfo?(nicolas.b.pierron) → needinfo?(kvijayan)
Tomcat:
Does this bug still reproduce?  If it's  a dup of 859609, it should be gone now, as that logic is bypassed with an #if 0.
Flags: needinfo?(kvijayan)
Flags: needinfo?(cbook)
Whiteboard: [dupe 859609?]
(In reply to Kannan Vijayan [:djvj] from comment #3)
> Tomcat:
> Does this bug still reproduce?  If it's  a dup of 859609, it should be gone
> now, as that logic is bypassed with an #if 0.

yeah seems its indeed a dupe, no longer crashes
Flags: needinfo?(cbook)
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.