Closed Bug 577705 Opened 14 years ago Closed 14 years ago

JM: "Assertion failure: -int32(uint8(-distance)) == distance,"

Categories

(Core :: JavaScript Engine, defect)

x86
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: gkw, Unassigned)

References

Details

(Keywords: assertion, regression, testcase)

Attachments

(1 file)

Attached js file asserts js debug shell on JM tip with -m at:

Assertion failure: -int32(uint8(-distance)) == distance, at ../methodjit/Compiler.cpp:319

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x0015f85d in JS_Assert (s=0x2599f4 "-int32(uint8(-distance)) == distance", file=0x259310 "../methodjit/Compiler.cpp", ln=319) at ../jsutil.cpp:77
77          *((int *) NULL) = 0;  /* To continue from here in GDB: "return" then "continue". */
(gdb) bt
#0  0x0015f85d in JS_Assert (s=0x2599f4 "-int32(uint8(-distance)) == distance", file=0x259310 "../methodjit/Compiler.cpp", ln=319) at ../jsutil.cpp:77
#1  0x0020e048 in js::mjit::Compiler::finishThisUp (this=0xbfffdc00) at ../methodjit/Compiler.cpp:319
#2  0x0020e617 in js::mjit::Compiler::Compile (this=0xbfffdc00) at ../methodjit/Compiler.cpp:142
#3  0x0020e8ca in js::mjit::TryCompile (cx=0x809200, script=0x512b10, fun=0x70b230, scopeChain=0x701000) at ../methodjit/Compiler.cpp:170
#4  0x00235f3e in InlineCall (f=@0xbffff4a0, flags=0, pret=0xbffff444, argc=0) at ../methodjit/InvokeHelpers.cpp:274
#5  0x00236349 in js::mjit::stubs::SlowCall (f=@0xbffff4a0, argc=0) at ../methodjit/InvokeHelpers.cpp:374
#6  0x0064528c in ?? ()
#7  0x001f1223 in js::mjit::JaegerShot (cx=0x809200) at ../methodjit/MethodJIT.cpp:638
#8  0x000b4942 in js::RunScript (cx=0x809200, script=0x512f20, fun=0x0, scopeChain=0x701000) at jsinterp.cpp:466
#9  0x000b5eb2 in js::Execute (cx=0x809200, chain=0x701000, script=0x512f20, down=0x0, flags=0, result=0xbffff6c0) at jsinterp.cpp:931
#10 0x00017286 in JS_ExecuteScript (cx=0x809200, obj=0x701000, script=0x512f20, rval=0xbffff6c0) at ../jsapi.cpp:4637
#11 0x0000c038 in Process (cx=0x809200, obj=0x701000, filename=0x0, forceTTY=0) at ../../shell/js.cpp:533
#12 0x0000ca3b in ProcessArgs (cx=0x809200, obj=0x701000, argv=0xbffff88c, argc=1) at ../../shell/js.cpp:860
#13 0x0000cb54 in shell (cx=0x809200, argc=1, argv=0xbffff88c, envp=0xbffff894) at ../../shell/js.cpp:5038
#14 0x0000cc78 in main (argc=1, argv=0xbffff88c, envp=0xbffff894) at ../../shell/js.cpp:5129
(In reply to comment #1)
> Created an attachment (id=456598) [details]
> testcase

Actually tested on moo tip changeset 9ba6da86ba7b.
This is happening because there are like 30 spills on the out-of-line transition to a getprop. The PIC structure assumes that this won't happen and stores a distance in a bitfield.

The real bug is that there are so many spills.
Hrm. It's not so easy to get rid of these spills because of exceptions. Say we have:

> function (x) {
>   try {
>     var a = [];
>     x.y;
>   } catch {
>     print(a);
>   }
> }

At |x.y|, the type of |a| is known and constant, and the GETPROP does not depend on it. However, we still sync it when transitioning from the inline fast path to the OOL slow path. We can fix this and get a perf win, and fix the original bug at the same time.

But if ic::GetProp throws, we'll resume at "print", and |a| will be undefined, because it was never synced on either the fast path or OOL path.

Bleh.

The easiest solution here is to know when we're in a try block, and to sync everything if so. Unfortunately, that doesn't completely solve the original bug. Maybe we should investigate having side exits like jstracer and attaching them to each OOL slow call in a try.

For now, just mitigation+perf win and increasing the bitfield size seems best.
A testcase for this bug was automatically identified at js/src/jit-test/tests/jaeger/bug577705.js.
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: