862328 - IonMonkey: Compartment mismatch with eval and timeout, or Crash [@ getName]

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 1d9c510b3742 (no options required):


var otherGlobalSameCompartment = newGlobal("same-compartment");
eval = otherGlobalSameCompartment.eval;
eval("timeout(1);");
eval('\
function timeoutfunc()  { print("Timed out"); }\
timeout(1, timeoutfunc);\
');
for (;;)
  function x(b, x) {}

Comment 1

[Christian Holler (:decoder)]

Crash trace:

Program received signal SIGSEGV, Segmentation fault.
getName (pc=0x86d71e8  <incomplete sequence \323>, this=<optimized out>) at ../jsscript.h:918
918             return getAtom(GET_UINT32_INDEX(pc))->asPropertyName();
(gdb) bt
#0  getName (pc=0x86d71e8  <incomplete sequence \323>, this=<optimized out>) at ../jsscript.h:918
#1  js::NameOperation (cx=0x8656ff0, pc=0x86d71e8  <incomplete sequence \323>, vp=$jsval(-nan(0xfff8200000000))) at js/src/jsinterpinlines.h:438
#2  0x080f71a2 in js::Interpret (cx=0x8656ff0, entryFrame=0xf7716078, interpMode=js::JSINTERP_NORMAL, useNewType=false) at js/src/jsinterp.cpp:2532
#3  0x08103185 in js::RunScript (cx=0x8656ff0, fp=0xf7716078) at js/src/jsinterp.cpp:365
#4  0x08103660 in js::InvokeKernel (cx=0x8656ff0, args=..., construct=js::NO_CONSTRUCT) at js/src/jsinterp.cpp:422
#5  0x08103d7a in Invoke (construct=js::NO_CONSTRUCT, args=..., cx=0x8656ff0) at js/src/jsinterp.h:135
#6  js::Invoke (cx=0x8656ff0, thisv=..., fval=..., argc=0, argv=0x0, rval=0xffffc528) at js/src/jsinterp.cpp:455
#7  0x0806c872 in JS_CallFunctionValue (cx=0x8656ff0, objArg=0x0, fval=$jsval(-nan(0xfff87f753fe00)), argc=0, argv=0x0, rval=0xffffc528) at js/src/jsapi.cpp:5875
#8  0x08054c4d in ShellOperationCallback (cx=0x8656ff0) at js/src/shell/js.cpp:362
#9  ShellOperationCallback (cx=0x8656ff0) at js/src/shell/js.cpp:352
#10 0x08097963 in js_InvokeOperationCallback (cx=0x8656ff0) at js/src/jscntxt.cpp:1147
#11 js_HandleExecutionInterrupt (cx=0x8656ff0) at js/src/jscntxt.cpp:1155
#12 0x083ec3e0 in js::ion::InterruptCheck (cx=0x8656ff0) at js/src/ion/VMFunctions.cpp:452
#13 0xf770e8c9 in ?? ()
#14 0xf770762e in ?? ()
#15 0x08333f61 in EnterBaseline (cx=0xf7529100, fp=0xf770f1f4, jitcode=0xf770f1c5, osr=true) at js/src/ion/BaselineJIT.cpp:154
#16 0x080f9f9b in js::Interpret (cx=0x8656ff0, entryFrame=0xf7716028, interpMode=js::JSINTERP_NORMAL, useNewType=false) at js/src/jsinterp.cpp:1465
#17 0x08103185 in js::RunScript (cx=0x8656ff0, fp=0xf7716028) at js/src/jsinterp.cpp:365
#18 0x08109eb5 in ExecuteKernel (result=0x0, evalInFrame=..., thisv=..., scopeChainArg=..., script=0xf7529100, cx=0x8656ff0, type=<optimized out>) at js/src/jsinterp.cpp:553
#19 js::Execute (cx=0x8656ff0, script=0xf7529100, scopeChainArg=(JSObject &) @0xf7525040 [object global] delegate, rval=0x0) at js/src/jsinterp.cpp:593
#20 0x0806ca38 in JS_ExecuteScript (cx=0x8656ff0, objArg=(JSObject *) 0xf7525040 [object global] delegate, scriptArg=0xf7529100, rval=0x0) at js/src/jsapi.cpp:5636
#21 0x08056f3e in Process (cx=0x8656ff0, obj_=<optimized out>, filename=0xffffd089 "min.js", forceTTY=false) at js/src/shell/js.cpp:469
#22 0x0805a386 in ProcessArgs (op=0xffffcdc0, obj_=(JSObject *) 0xf7525040 [object global] delegate, cx=0x8656ff0) at js/src/shell/js.cpp:5102
#23 Shell (cx=0x8656ff0, op=0xffffcdc0, envp=0xffffcee0) at js/src/shell/js.cpp:5139
#24 0x0804b818 in main (argc=2, argv=0xffffced4, envp=0xffffcee0) at js/src/shell/js.cpp:5376
(gdb) x /i $pc
=> 0x80f2ca3 <js::NameOperation(JSContext*, unsigned char*, JS::MutableHandle<JS::Value>)+451>: mov    0x14(%edx),%edx
(gdb) info reg edx
edx            0x0      0


The crash looks harmless but marking s-s due to compartment mismatch for now.

Comment 2

[Christian Holler (:decoder)]

A general notice: It might be easier to test stuff going through js_InvokeOperationCallback if we had a way to trigger it that doesn't use time. Time is problematic because it depends on execution speed which varies in the fuzzer during initial run and replay. In this particular case it works because there's an infinite loop at the end and it doesn't seem to matter in which exact state we're hitting the callback. I could imagine a function where you can specify a count after which the callback should be enabled, rather than seconds.

Comment 3

[Christian Holler (:decoder)]

JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   122494:851342f5eafe
user:        Nicholas D. Matsakis
date:        Tue Feb 19 09:23:31 2013 -0500
summary:     Bug 842745 - Modify timer in JS shell function to take an arbitrary JS function. r=dvander

This iteration took 115.212 seconds to run.

Comment 4

[Christian Holler (:decoder)]

Might be shell-only based on comment 3, needinfo from Nicholas :)

Comment 5

[Niko Matsakis [:nmatsakis]]

This particular bug is certainly shell-only.  I modified the timer so that you could inject cause arbitrary JS to execute during the callback, so as to better simulate what occurs in the browser with things like the Slow Script dialog.  It seems like it would be useful to have the fuzzer attempt inserting random things in this callback, but I guess we need some sanity checks (such as same compartment) to prevent it from generating too many error reports.

Comment 6

[Jesse Ruderman]

(In reply to Christian Holler (:decoder) from comment #2)
> A general notice: It might be easier to test stuff going through
> js_InvokeOperationCallback if we had a way to trigger it that doesn't use
> time.

I also requested this, in bug 831046.

Comment 7

[Niko Matsakis [:nmatsakis]]

It is unclear to me what action, if any, is required of me at this point.

Comment 8

[Christian Holler (:decoder)]

Unhiding based on comment 5.

Niko, just go ahead and fix this particular bug when you have time, no special action required :)

Comment 9

[Christian Holler (:decoder)]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision 8f0d4afd151e).

Comment 10

[Christian Holler (:decoder)]

Probably fixed by bug 956316.

Comment 11

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

=== Tinderbox Build Bisection Results by autoBisect ===

The "bad" changeset has the timestamp "20140103075726" and the hash "a21ca8f06806".
The "good" changeset has the timestamp "20140103081527" and the hash "2c02eb3d4b61".

Likely fix window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a21ca8f06806&tochange=2c02eb3d4b61

Yes, it's likely FIXED by bug 956316.

Comment 12

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically verified fixed.