Closed Bug 484751 Opened 12 years ago Closed 11 years ago

TM: "Assertion failure: !OBJ_GET_CLASS(cx, proto)->getObjectOps, at ../jsobj.cpp"

Categories

(Core :: JavaScript Engine, defect, P2)

defect

Tracking

()

VERIFIED FIXED
mozilla1.9.2a1

People

(Reporter: gkw, Assigned: Waldo)

References

Details

(4 keywords, Whiteboard: fixed-in-tracemonkey)

Attachments

(3 files)

__defineGetter__("x3", Function)
undefined = x3;
undefined.prototype = []
for (var z = 0; z < 4; ++z) { new undefined() }

Assertion failure: !OBJ_GET_CLASS(cx, proto)->getObjectOps, at ../jsobj.cpp:2008

(debug js shell with -j)

split off from https://bugzilla.mozilla.org/show_bug.cgi?id=452498#c162

autoBisect shows this is probably related to bug 480759 or http://hg.mozilla.org/tracemonkey/rev/1acc565e2e7c :

The first bad revision is:
changeset:   25738:1acc565e2e7c
user:        Brendan Eich
date:        Wed Mar 04 19:26:16 2009 -0800
summary:     Bug 480759 - TM: trace RegExp constructors (r=gal).

Assigning to Waldo at his request.
Flags: blocking1.9.1?
For reference, here's a slightly simplified testcase without all that crazy undefined-redefining jazz:

function f() {}
f.prototype = []
for (var z = 0; z < 4; ++z) { new f() }
Flags: blocking1.9.1? → blocking1.9.1+
0:000> !exploitable -v
HostMachine\HostUser
Executing Processor Architecture is x86

/snip

Exception Faulting Address: 0x7c90120e
First Chance Exception Type: STATUS_BREAKPOINT (0x80000003)

Faulting Instruction:7c90120e int 3

Basic Block:
    7c90120e int 3

Exception Hash (Major/Minor): 0x7c3a7777.0x6b3b3003

Stack Trace:
ntdll!DbgBreakPoint+0x0
js3250!JS_Assert+0x2d
js3250!NewNativeObject+0xce
js3250!js_NewInstance+0x357
Unknown
js3250!js_ExecuteTree+0x51f
js3250!js_MonitorLoopEdge+0x2d7
js3250!js_Interpret+0x5cb9
js3250!js_Execute+0x2dc
js3250!JS_EvaluateUCScriptForPrincipals+0xe5
gklayout!nsJSContext::EvaluateString+0x2ba
gklayout!nsScriptLoader::EvaluateScript+0x37a
gklayout!nsScriptLoader::ProcessRequest+0xfd
gklayout!nsScriptLoader::ProcessScriptElement+0x1031
gklayout!nsScriptElement::MaybeProcessScript+0x149
gklayout!nsHTMLScriptElement::MaybeProcessScript+0x24
gklayout!nsHTMLScriptElement::DoneAddingChildren+0x1f
gklayout!HTMLContentSink::ProcessSCRIPTEndTag+0xcf
gklayout!SinkContext::CloseContainer+0x31d
gklayout!HTMLContentSink::CloseContainer+0xa0
gkparser!CNavDTD::CloseContainer+0x18a
gkparser!CNavDTD::HandleEndToken+0x1dd
gkparser!CNavDTD::HandleToken+0x4ae
gkparser!CNavDTD::BuildModel+0x295
gkparser!nsParser::BuildModel+0xe2
gkparser!nsParser::ResumeParse+0x1bc
gkparser!nsParser::OnDataAvailable+0x228
docshell!nsDocumentOpenInfo::OnDataAvailable+0x4c
necko!nsBaseChannel::OnDataAvailable+0x6d
necko!nsInputStreamPump::OnStateTransfer+0x23d
necko!nsInputStreamPump::OnInputStreamReady+0x80
xpcom_core!nsInputStreamReadyEvent::Run+0x4a
xpcom_core!nsThread::ProcessNextEvent+0x1fa
xpcom_core!NS_ProcessNextEvent_P+0x53
gkwidget!nsBaseAppShell::Run+0x5d
tkitcmps!nsAppStartup::Run+0x6b
xul!XRE_main+0x3388
firefox!NS_internal_main+0x2b2
firefox!wmain+0x119
firefox!__tmainCRTStartup+0x1a8
firefox!wmainCRTStartup+0xf
kernel32!BaseProcessStart+0x23
Instruction Address: 0x7c90120e

Description: Possible Stack Corruption
Short Description: PossibleStackCorruption
Exploitability Classification: UNKNOWN
Recommended Bug Title: Possible Stack Corruption starting at ntdll!DbgBreakPoint+0x0 (Hash=0x7c3a7777.0x6b3b3003)

The stack trace contains one or more locations for which no symbol or module could be found. This may be a sign of stack corruption.
gary: you need to sympath/symfix first. and note that !exploitable's output for Breakpoints is basically "breakpoints shouldn't happen in release builds, this might be a bug, but there's not much i can know about it".
It isn't clear to me that running !exploitable on a debug build (for an assertion testcase) is useful. It'll always just hit the "breakpoint" code in JS_Assert. Whether or not this is exploitable depends on what happens in optimized builds after the assertion.
(In reply to comment #4)
> It isn't clear to me that running !exploitable on a debug build (for an
> assertion testcase) is useful. It'll always just hit the "breakpoint" code in
> JS_Assert. Whether or not this is exploitable depends on what happens in
> optimized builds after the assertion.

Yeah, I agree, and figured it out later after considering various scenarios. (after I had commented in the bug) The curious thing is why !exploitable shows this as "possible stack corruption" instead of breakpoint, towards the end result.
(In reply to comment #5)
> The curious thing is why !exploitable shows
> this as "possible stack corruption" instead of breakpoint, towards the end
> result.

See the very end:
> The stack trace contains one or more locations for which no symbol or
> module could be found. This may be a sign of stack corruption.

!exploitable is getting confused by us running JIT code.
Priority: -- → P2
Attachment #370278 - Flags: review?(mrbkap)
Attachment #370278 - Flags: review?(mrbkap) → review+
http://hg.mozilla.org/tracemonkey/rev/d4bbfed24621
OS: Mac OS X → All
Hardware: x86 → All
Whiteboard: fixed-in-tracemonkey
Linux-x86 crashes on trace-test in the original patch. Need this followup to work.
Attachment #370334 - Flags: review?(mrbkap)
Attachment #370334 - Flags: review?(mrbkap) → review+
http://hg.mozilla.org/mozilla-central/rev/d4bbfed24621
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
(In reply to comment #11)
> http://hg.mozilla.org/mozilla-central/rev/d4bbfed24621

Sayre: please be sure to migrate the followup noted in comment 10 as well.
(In reply to comment #12)
> (In reply to comment #11)
> > http://hg.mozilla.org/mozilla-central/rev/d4bbfed24621
> 
> Sayre: please be sure to migrate the followup noted in comment 10 as well.

Don't worry, it's automatic in mozilla-central's case and easy to see in the pushloghtml otherwise.
Flags: in-testsuite+
Verified fixed with testcase given in comment 0 on trunk and 1.9.1 with the
following debug builds:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre)
Gecko/20090422 Minefield/3.6a1pre ID:20090422224452

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre)
Gecko/20090422 Shiretoko/3.5b4pre ID:20090422122043
Status: RESOLVED → VERIFIED
Target Milestone: --- → mozilla1.9.2a1
Flags: wanted1.9.0.x-
cvsroot/mozilla/js/tests/js1_8_1/trace/trace-test.js,v  <--  trace-test.js
new revision: 1.14; previous revision: 1.13

/cvsroot/mozilla/js/tests/shell.js,v  <--  shell.js
You need to log in before you can comment on or make changes to this bug.