Closed Bug 732847 Opened 12 years ago Closed 12 years ago

IonMonkey: Crash on Heap near [@ js::ObjectImpl::getClass]

Categories

(Core :: JavaScript Engine, defect)

Other Branch
x86_64
Linux
defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: decoder, Assigned: nbp)

References

Details

(Keywords: crash, testcase)

Crash Data

Attachments

(2 files, 1 obsolete file)

Attached file Testcase for shell
The attached testcase crashes on ionmonkey revision 1fd6c40d3852 (run with --ion -n -m), tested on 64 bit.
Crash trace:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7f4090f in ?? ()
(gdb) bt
#0  0x00007ffff7f4090f in ?? ()
#1  0x00007fffffffc4b0 in ?? ()
#2  0xfff9000000000000 in ?? ()
#3  0x00000000004153a4 in js::ObjectImpl::getClass (this=0x2) at ../../vm/ObjectImpl-inl.h:31
#4  0x0000000000761708 in EnterIon (cx=0xcd5d00, fp=0x7ffff0beb1e8, target=..., jitcode=0x7ffff7f406d8, osr=false)
    at /home/ownhero/homes/mozilla/repos/ionmonkey/js/src/ion/Ion.cpp:941
#5  0x000000000076194a in js::ion::Cannon (cx=0xcd5d00, fp=0x7ffff0beb1e8) at /home/ownhero/homes/mozilla/repos/ionmonkey/js/src/ion/Ion.cpp:970
#6  0x000000000050d28a in js::Interpret (cx=0xcd5d00, entryFrame=0x7ffff0beb030, interpMode=js::JSINTERP_NORMAL)
    at /home/ownhero/homes/mozilla/repos/ionmonkey/js/src/jsinterp.cpp:2793
Assignee: general → nicolas.b.pierron
Status: NEW → ASSIGNED
The following test case highlight the issue with --ion -n:


---
var callStack = [];
function currentFunc() {
    return callStack[0];
}
function reportFailure () {
    var funcName = currentFunc();
    // play with the result to cause a SEGV.
    var prefix = (funcName) ? funcName : "";
    // Use OSR to compile the function at the end of the first run.
    for (var i=0; i < 50; i++) ;
}

callStack[0] = 'test';
// Run and compile with a string as result of currentFunc.
reportFailure();
callStack[0] = undefined;
// Use previously compiled code with the string assumption.
reportFailure();
---



The problem is that Type Inference does not set the monitoredTypesReturn flag to the call of currentFunc.  The output of the types at the moment of the MIR creation looks like:



(gdb) call cx->compartment->types.print(cx, true)
Function #2 _build/bug732847.js (line 7):
locals:
    return: void
    this: void
#2:00000:   8  callgname "currentFunc"
  typeset 0: object[1] <0x7ffff0a10800>
  type 0: object[1] <0x7ffff0a10800>
#2:00005:   8  undefined
  type 0: void
#2:00006:   8  notearg
#2:00007:   8  call 0
  typeset 1: string
  type 0: string
#2:00010:   8  setlocal 0
  type 0: string
#2:00013:   8  pop
#2:00014:  10  getlocal 0
  type 0: string
#2:00017:  10  ifeq 30 (+13)
#2:00022:  10  getlocal 0
  type 0: string
#2:00025:  10  goto 35 (+10)
#2:00030:  10  string ""
  type 0: string
#2:00035:  10  setlocal 1
  type 0: string
#2:00038:  10  pop
#2:00039:  12  zero
  type 0: int
#2:00040:  12  setlocal 2
  type 0: int
#2:00043:  12  pop
#2:00044:  12  goto 54 (+10)
#2:00049:  12  loophead
#2:00050:  12  localinc 2
  type 0: int
#2:00053:  12  pop
#2:00054:  12  loopentry
#2:00055:  12  getlocal 2
  type 0: int
#2:00058:  12  int8 50
  type 0: int
#2:00060:  12  lt
  type 0: bool
#2:00061:  12  ifne 49 (-12)
#2:00066:  12  stop

[0x7ffff0a00040] : (null) unknown {}
int : (null) {}
[0x7ffff0a000a0] : <0x7ffff0a05020> unknown {}
int : <0x7ffff0a05020> {}
[0x7ffff0a00100] : <0x7ffff0a06040> unknown {}
int : <0x7ffff0a06040> {}
<0x7ffff0a03060> : <0x7ffff0a05020> {
    currentFunc: [own] object[1] <0x7ffff0a10800>
}
<0x7ffff0a05020> : (null) {
    currentFunc: missing
}
[0x7ffff0a001c0] : <0x7ffff0a05060> unknown {}
[0x7ffff0a001f0] : <0x7ffff0a05060> packed dense {
    (index): [own] string
}
Counts: 14/0/0/0 (0 over)
Recompilations: 0



This does not change, even after the second execution of currentFunc.



(gdb) call js_DumpScript(cx, (JSScript*)0x7ffff0a07180)
loc   line  op
----- ----  --
main:
00000:   3  getgname "callStack"
00005:   3  zero
00006:   3  getelem
00007:   3  return
00008:   3  stop



IonMonkey does not produce any type barrier because the enalysis at the call-site (#2 @ 7) does not report any need for a monitoredTypesReturn.



(gdb) p ((JSScript * const) 0x7ffff0a07268)->analysis()->getCode((jsbytecode *) 0xd13757)
$11 = (js::analyze::Bytecode &) @0x7ffff7f5deb0: {
  jumpTarget = false,
  fallthrough = true,
  jumpFallthrough = false, 
  switchTarget = false,
  unconditional = true,
  analyzed = true,
  exceptionEntry = false,
  inTryBlock = false,
  inLoop = false, 
  safePoint = false,
  monitoredTypes = false,
  monitoredTypesReturn = false,
  arrayWriteHole = false,
  getStringElement = false, 
  accessGetter = false,
  stackDepth = 2,
  {observedTypes = 0xd15008, loop = 0xd15008},
  allocation = 0x0, 
  poppedValues = 0x7ffff7f5e730,
  pushedUses = 0x7ffff7f5e780,
  {newValues = 0x0, pendingValues = 0x0},
  pushedTypes = 0x7ffff7f5ee40, 
  typeBarriers = 0x0
}
The current implementation in JM uses a TypeMonitor on the result if the function call succeeded.  This can be implemented with a MMonitorType which does the same as a TypeBarrier and only create a difference at Bailout time.


// UncachedInlineCall in InvokHelpers.h
    bool ok = !!Interpret(cx, cx->fp());
    f.cx->stack.popInlineFrame(regs);

    if (ok)
        types::TypeScript::Monitor(f.cx, f.script(), f.pc(), args.rval());


(Thanks jandem)
This patch fix the issue reported in this bug when ionmonkey is executed with --ion -n.  It also reveal a bug with --ion -n --ion-eager on the same test-case.

I am will investigate this second issue and discard this patch once I have the --ion-eager fix.
Add monitoring of the returned values of interpreted function and ensure that type compile info are accurate by adding a watchdog.
Attachment #609541 - Attachment is obsolete: true
Attachment #609576 - Flags: review?(jdemooij)
Comment on attachment 609576 [details] [diff] [review]
Monitor interpreted functions and Guard on compile info.

Review of attachment 609576 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/ion/TypeOracle.cpp
@@ +419,5 @@
> +    if (script->analysis()->usesScopeChain())
> +        return false;
> +
> +    if (types::TypeSet::HasObjectFlags(cx, target->getType(cx), types::OBJECT_FLAG_UNINLINEABLE))
> +        return false;

Nice catch!
Attachment #609576 - Flags: review?(jdemooij) → review+
https://hg.mozilla.org/projects/ionmonkey/rev/4e9eeb5ae686
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
A testcase for this bug was automatically identified at js/src/jit-test/tests/ion/bug732847.js.
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.