Closed Bug 585824 Opened 14 years ago Closed 14 years ago

TM: Assertion failure: kind == GetFinalizableThingTraceKind(thing) in testSlowNativeBail.js

Categories

(Core :: JavaScript Engine, defect)

x86_64
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: gwagner, Assigned: luke)

Details

(Whiteboard: [sg:critical?] fixed-in-tracemonkey)

Attachments

(1 file)

current tip with gczeal = 2!

Starting program: /Users/idefix2/moz/meter2/js/src/DBG.OBJ/js -j ../trace-test/tests/basic/testSlowNativeBail.js
Reading symbols for shared libraries .++++..................................................................................... done
Assertion failure: kind == GetFinalizableThingTraceKind(thing), at ../jsgc.cpp:2115

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x000000010016783d in JS_Assert (s=0x100206b50 "kind == GetFinalizableThingTraceKind(thing)", file=0x100205f68 "../jsgc.cpp", ln=2115) at ../jsutil.cpp:81
81	    *((int *) NULL) = 0;  /* To continue from here in GDB: "return" then "continue". */
(gdb) bt
#0  0x000000010016783d in JS_Assert (s=0x100206b50 "kind == GetFinalizableThingTraceKind(thing)", file=0x100205f68 "../jsgc.cpp", ln=2115) at ../jsutil.cpp:81
#1  0x0000000100080556 in js::Mark (trc=0x7fff5fbfc910, thing=0x101503510, kind=1) at ../jsgc.cpp:2115
#2  0x0000000100040f20 in js::MarkValueRaw (trc=0x7fff5fbfc910, v=@0x101000268) at jsgc.h:677
#3  0x0000000100040f8e in js::MarkValueRange (trc=0x7fff5fbfc910, beg=0x101000250, end=0x101000278, name=0x100202937 "stack") at jsgc.h:692
#4  0x0000000100041081 in js::StackSpace::mark (this=0x10048c658, trc=0x7fff5fbfc910) at ../jscntxt.cpp:216
#5  0x00000001000411c3 in JSThreadData::mark (this=0x10048c5e8, trc=0x7fff5fbfc910) at ../jscntxt.cpp:558
#6  0x000000010008189c in js_TraceRuntime (trc=0x7fff5fbfc910) at ../jsgc.cpp:2531
#7  0x0000000100082759 in GC (cx=0x100512590) at ../jsgc.cpp:3071
#8  0x0000000100083a58 in GCUntilDone (cx=0x100512590, gckind=GC_LOCK_HELD) at ../jsgc.cpp:3443
#9  0x0000000100083b8c in js_GC (cx=0x100512590, gckind=GC_LOCK_HELD) at ../jsgc.cpp:3497
#10 0x0000000100083c88 in LastDitchGC (cx=0x100512590) at ../jsgc.cpp:1618
#11 0x0000000100084241 in RefillFinalizableFreeList (cx=0x100512590, thingKind=1) at ../jsgc.cpp:1642
#12 0x0000000100084596 in js_NewFinalizableGCThing (cx=0x100512590, thingKind=1) at ../jsgc.cpp:1730
#13 0x00000001000756b2 in js_NewGCFunction (cx=0x100512590) at jsgc.h:300
#14 0x0000000100075df3 in js::detail::NewObject<false, true> (cx=0x100512590, clasp=0x100299560, proto=0x101505000, parent=0x101503000) at jsobjinlines.h:702
#15 0x0000000100075edd in js::NewFunction (cx=0x100512590, proto=0x0, parent=0x101503000) at jsobjinlines.h:734
#16 0x0000000100075f4e in js_NewFunction (cx=0x100512590, funobj=0x0, native=0x100072da7 <Exception(JSContext*, JSObject*, unsigned int, js::Value*, js::Value*)>, nargs=3, flags=0, parent=0x101503000, atom=0x1015006c0) at ../jsfun.cpp:2429
#17 0x0000000100076179 in js_DefineFunction (cx=0x100512590, obj=0x101503000, atom=0x1015006c0, native=0x100072da7 <Exception(JSContext*, JSObject*, unsigned int, js::Value*, js::Value*)>, nargs=3, attrs=0) at ../jsfun.cpp:2582
#18 0x0000000100070365 in js_InitExceptionClasses (cx=0x100512590, obj=0x101503000) at ../jsexn.cpp:1033
#19 0x00000001000cd259 in js_GetClassObject (cx=0x100512590, obj=0x101503000, key=JSProto_SyntaxError, objp=0x7fff5fbfcff8) at ../jsobj.cpp:3706
#20 0x00000001000d1f23 in js_FindClassObject (cx=0x100512590, start=0x0, protoKey=JSProto_SyntaxError, vp=0x7fff5fbfd080, clasp=0x0) at ../jsobj.cpp:3771
#21 0x00000001000d2125 in js::FindClassPrototype (cx=0x100512590, scope=0x101503000, protoKey=JSProto_SyntaxError, protop=0x7fff5fbfd178, clasp=0x0) at ../jsobj.cpp:5545
#22 0x00000001000d2938 in js_GetClassPrototype (cx=0x100512590, scope=0x101503000, protoKey=JSProto_SyntaxError, protop=0x7fff5fbfd178, clasp=0x0) at ../jsobj.cpp:5592
#23 0x0000000100072c3e in js_ErrorToException (cx=0x100512590, message=0x100514b40 "invalid quantifier +", reportp=0x7fff5fbfd260, callback=0x10003ca08 <js_GetErrorMessage(void*, char const*, unsigned int)>, userRef=0x0) at ../jsexn.cpp:1161
#24 0x000000010003fbca in ReportError (cx=0x100512590, message=0x100514b40 "invalid quantifier +", reportp=0x7fff5fbfd260, callback=0x10003ca08 <js_GetErrorMessage(void*, char const*, unsigned int)>, userRef=0x0) at ../jscntxt.cpp:1385
#25 0x000000010003fd66 in js_ReportErrorNumberVA (cx=0x100512590, flags=0, callback=0x10003ca08 <js_GetErrorMessage(void*, char const*, unsigned int)>, userRef=0x0, errorNumber=46, charArgs=0, ap=0x7fff5fbfd320) at ../jscntxt.cpp:1738
#26 0x00000001000121f9 in JS_ReportErrorFlagsAndNumberUC (cx=0x100512590, flags=0, errorCallback=0x10003ca08 <js_GetErrorMessage(void*, char const*, unsigned int)>, userRef=0x0, errorNumber=46) at ../jsapi.cpp:5375
#27 0x0000000100129ae9 in ReportRegExpErrorHelper (state=0x7fff5fbfd5d0, flags=0, errorNumber=46, arg=0x10029d880) at ../jsregexp.cpp:483
#28 0x000000010012baeb in ParseTerm (state=0x7fff5fbfd5d0) at ../jsregexp.cpp:1496
#29 0x000000010012c309 in ParseRegExp (state=0x7fff5fbfd5d0) at ../jsregexp.cpp:708
#30 0x000000010012cad5 in CompileRegExpToAST (cx=0x100512590, ts=0x0, str=0x10029d870, flags=0, state=@0x7fff5fbfd5d0) at ../jsregexp.cpp:2031
#31 0x000000010012cb6a in js_NewRegExp (cx=0x100512590, ts=0x0, str=0x10029d870, flags=0, flat=0) at ../jsregexp.cpp:3398
#32 0x000000010012d290 in js_NewRegExpOpt (cx=0x100512590, str=0x10029d870, opt=0x0, flat=0) at ../jsregexp.cpp:3497
#33 0x000000010012d724 in regexp_compile_sub (cx=0x100512590, obj=0x101503510, argc=1, argv=0x7fff5fbfd870, rval=0x7fff5fbfd878) at ../jsregexp.cpp:5614
#34 0x000000010012da2b in RegExp (cx=0x100512590, obj=0x101503510, argc=1, argv=0x7fff5fbfd870, rval=0x7fff5fbfd878) at ../jsregexp.cpp:5777
#35 0x00000001004c0f21 in ?? ()
#36 0x000000010018c286 in js::ExecuteTrace (cx=0x100512590, f=0x10089f620, state=@0x7fff5fbfd950) at ../jstracer.cpp:6654
#37 0x000000010019840e in js::ExecuteTree (cx=0x100512590, f=0x10089f620, inlineCallCount=@0x7fff5fbfe6bc, innermostNestedGuardp=0x7fff5fbfdab0, lrp=0x7fff5fbfdab8) at ../jstracer.cpp:6755
#38 0x00000001001a9937 in js::MonitorLoopEdge (cx=0x100512590, inlineCallCount=@0x7fff5fbfe6bc, reason=js::Record_Branch) at ../jstracer.cpp:7260
#39 0x000000010009b19d in js::Interpret (cx=0x100512590) at ../jsinterp.cpp:3374
#40 0x00000001000b98d1 in js::Execute (cx=0x100512590, chain=0x101503000, script=0x100514a40, down=0x0, flags=0, result=0x0) at jsinterp.cpp:907
#41 0x0000000100016257 in JS_ExecuteScript (cx=0x100512590, obj=0x101503000, script=0x100514a40, rval=0x0) at ../jsapi.cpp:4752
#42 0x000000010000a555 in Process (cx=0x100512590, obj=0x101503000, filename=0x7fff5fbffa17 "../trace-test/tests/basic/testSlowNativeBail.js", forceTTY=0) at ../../shell/js.cpp:440
#43 0x000000010000b18b in ProcessArgs (cx=0x100512590, obj=0x101503000, argv=0x7fff5fbff8f0, argc=2) at ../../shell/js.cpp:854
#44 0x000000010000b273 in shell (cx=0x100512590, argc=2, argv=0x7fff5fbff8f0, envp=0x7fff5fbff908) at ../../shell/js.cpp:5047
#45 0x000000010000b36f in main (argc=2, argv=0x7fff5fbff8f0, envp=0x7fff5fbff908) at ../../shell/js.cpp:5134
Very strange. It starts with revision 48355.

changeset:   48355:babf32a45349
user:        Andreas Gal <gal@mozilla.com>
date:        Wed Jul 28 11:20:19 2010 -0700
files:       dom/base/nsJSEnvironment.cpp js/src/jsapi.cpp js/src/jscntxt.cpp js/src/jscntxt.h js/src/jsgc.cpp js/src/jsgc.h js/src/jsscope.cpp js/src/jsscope.h js/src/jstracer.cpp
description:
Back out bug 580803.
Hardware: x86 → x86_64
I tracked down the problem a bit.  The problem is that, for the expression

  new RegExp(a[i])

(which deep bails inside RegExp, LeaveTree thinks that the 'this' parameter on the expr stack has type null when its slot actually holds a valid JSObject*.  The low-level details of Value::boxNonDoubleFrom() just do payload | tag (thereby avoiding type-specific branching), so the non-null payload enters the value and later confuses the v.isMarkable() query.

I think this is an issue of when snapshots are taken vs. when set(&vp[1], this_ins) happens when tracing calls to slow natives.
This is a continuation of the problems with bug 581784.  callNative may update 'this' in the tracker, but the snapshot taken by enterDeepBailCall happens while vp[1] still holds null, hence the null trace type.  The solution seems to be eagerly update vp[1] to match whats in the tracker.
Does this problem also affect the branches as bug 581784 did?
Whiteboard: [sg:critical?]
(In reply to comment #4)
> Does this problem also affect the branches as bug 581784 did?

Yes.
So, IIUC, it looks like the branches don't have a problem after all: on 1.9.1 and 1.9.2, JSOP_NEW always takes an object as 'this', never null.  Is that right Brendan?

If so, then enterDeepBail will assign the correct type tag.  All the other paths seem to produce the right type of vp[1], except the JSFUN_BOUND_METHOD_TEST path.  mxr says we don't use this anywhere except nsJSSh, so unless there is some kookie side channel, this isn't exploitable.  (Btw, why in the world do we trace bound methods?  Can we remove bound methods altogether?)
Right, always a newborn object in |this| from JSOP_NEW. (Something we want to avoid and bhackett is/has in JM, but that is new.)

/be
Attached patch fixSplinter Review
I thought fast constructors would remove the need for js_NewInstance altogether, but calls to scripted constructors still need it.  So, since all we need is for the snapshoted type to agree with the LIR, the patch just assigns *some* object to vp[1].  Please see if you can find holes in this reasoning.
Assignee: general → lw
Status: NEW → ASSIGNED
Attachment #464996 - Flags: review?(gal)
Attachment #464996 - Flags: review?(dvander)
Attachment #464996 - Flags: review?(gal) → review+
http://hg.mozilla.org/tracemonkey/rev/c9eaa3d9ff39
Whiteboard: [sg:critical?] → [sg:critical?] fixed-in-tracemonkey
Legit -- in the TM "old days" I used to stuff jsval tag bits (no payload) into the right place ;-).

/be
word up
http://hg.mozilla.org/mozilla-central/rev/226f1bdcc25f
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Group: core-security
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: