Closed Bug 1253246 Opened 8 years ago Closed 8 years ago

Assertion failure: !scope->getOps()->setProperty, at js/src/vm/Interpreter-inl.h:281 with Debugger

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla48
Tracking Status
firefox47 --- fixed
firefox48 --- fixed

People

(Reporter: decoder, Unassigned)

References

Details

(Keywords: assertion, regression, testcase, Whiteboard: [jsbugmon:update])

Attachments

(1 file, 1 obsolete file)

The following testcase crashes on mozilla-central revision e15383656900 (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug, run with --fuzzing-safe --no-threads):

g = newGlobal();
g.parent = this;
g.eval("(" + function() {
    Debugger(parent).onExceptionUnwind = function(frame)
      frame.eval("for(c in [1,2,3,4]) {}")
} + ")()");
try {
  evalReturningScope("'use strict'; x = 1");
} catch (e) {}



Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x000000000063a02b in js::SetNameOperation (cx=0x7ffff6907800, script=<optimized out>, pc=<optimized out>, scope=..., val=...) at js/src/vm/Interpreter-inl.h:281
#0  0x000000000063a02b in js::SetNameOperation (cx=0x7ffff6907800, script=<optimized out>, pc=<optimized out>, scope=..., val=...) at js/src/vm/Interpreter-inl.h:281
#1  0x0000000000aaaba9 in Interpret (cx=cx@entry=0x7ffff6907800, state=...) at js/src/vm/Interpreter.cpp:2580
#2  0x0000000000ab9788 in js::RunScript (cx=cx@entry=0x7ffff6907800, state=...) at js/src/vm/Interpreter.cpp:428
#3  0x0000000000abf0e9 in js::ExecuteKernel (cx=cx@entry=0x7ffff6907800, script=..., script@entry=..., scopeChainArg=..., newTargetValue=..., evalInFrame=..., result=result@entry=0x7fffffffa700) at js/src/vm/Interpreter.cpp:684
#4  0x00000000009f004c in EvaluateInEnv (rval=..., lineno=<optimized out>, filename=<optimized out>, pc=<optimized out>, frame=..., env=..., cx=0x7ffff6907800, chars=...) at js/src/vm/Debugger.cpp:7005
#5  DebuggerGenericEval (cx=cx@entry=0x7ffff6907800, fullMethodName=fullMethodName@entry=0xeca6f6 "Debugger.Frame.prototype.eval", code=..., evalWithBindings=evalWithBindings@entry=EvalWithDefaultBindings, bindings=..., options=..., vp=..., dbg=dbg@entry=0x7ffff694e000, scope=..., scope@entry=..., iter=iter@entry=0x7fffffffaa58) at js/src/vm/Debugger.cpp:7138
#6  0x00000000009f0d32 in DebuggerFrame_eval (cx=0x7ffff6907800, argc=<optimized out>, vp=<optimized out>) at js/src/vm/Debugger.cpp:7152
#7  0x0000000000ac0722 in js::CallJSNative (cx=0x7ffff6907800, native=0x9f0ac0 <DebuggerFrame_eval(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:235
#8  0x0000000000ab9a71 in js::Invoke (cx=cx@entry=0x7ffff6907800, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:478
#9  0x0000000000aaa9d2 in Interpret (cx=cx@entry=0x7ffff6907800, state=...) at js/src/vm/Interpreter.cpp:2802
#10 0x0000000000ab9788 in js::RunScript (cx=cx@entry=0x7ffff6907800, state=...) at js/src/vm/Interpreter.cpp:428
#11 0x0000000000ab9acd in js::Invoke (cx=cx@entry=0x7ffff6907800, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:496
#12 0x0000000000aba59c in js::Invoke (cx=cx@entry=0x7ffff6907800, thisv=..., fval=..., argc=argc@entry=2, argv=argv@entry=0x7fffffffb920, rval=..., rval@entry=...) at js/src/vm/Interpreter.cpp:530
#13 0x00000000009f10af in js::Debugger::fireExceptionUnwind (this=this@entry=0x7ffff694e000, cx=cx@entry=0x7ffff6907800, vp=..., vp@entry=...) at js/src/vm/Debugger.cpp:1482
#14 0x00000000009f1482 in operator() (dbg=0x7ffff694e000, __closure=<synthetic pointer>) at js/src/vm/Debugger.cpp:890
#15 dispatchHook<js::Debugger::slowPathOnExceptionUnwind(JSContext*, js::AbstractFramePtr)::__lambda5, js::Debugger::slowPathOnExceptionUnwind(JSContext*, js::AbstractFramePtr)::__lambda6> (fireHook=..., cx=0x7ffff6907800, hookIsEnabled=...) at js/src/vm/Debugger.cpp:1659
#16 js::Debugger::slowPathOnExceptionUnwind (cx=cx@entry=0x7ffff6907800, frame=...) at js/src/vm/Debugger.cpp:891
#17 0x0000000000aaa68b in onExceptionUnwind (frame=..., cx=0x7ffff6907800) at js/src/vm/Debugger-inl.h:66
#18 HandleError (regs=..., cx=0x7ffff6907800) at js/src/vm/Interpreter.cpp:1174
#19 Interpret (cx=cx@entry=0x7ffff6907800, state=...) at js/src/vm/Interpreter.cpp:3965
#20 0x0000000000ab9788 in js::RunScript (cx=cx@entry=0x7ffff6907800, state=...) at js/src/vm/Interpreter.cpp:428
#21 0x0000000000abf0e9 in js::ExecuteKernel (cx=cx@entry=0x7ffff6907800, script=..., script@entry=..., scopeChainArg=..., newTargetValue=..., evalInFrame=..., evalInFrame@entry=..., result=result@entry=0x7fffffffc780) at js/src/vm/Interpreter.cpp:684
#22 0x00000000005d99d5 in js::ExecuteInGlobalAndReturnScope (cx=cx@entry=0x7ffff6907800, global=..., global@entry=..., scriptArg=..., scriptArg@entry=..., scopeArg=..., scopeArg@entry=...) at js/src/builtin/Eval.cpp:485
#23 0x0000000000a42167 in EvalReturningScope (cx=0x7ffff6907800, argc=<optimized out>, vp=<optimized out>) at js/src/builtin/TestingFunctions.cpp:2864
#24 0x0000000000ac0722 in js::CallJSNative (cx=0x7ffff6907800, native=0xa41c80 <EvalReturningScope(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:235
[...]
#36 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at js/src/shell/js.cpp:7244
rax	0x0	0
rbx	0x7ffff7e6a1f0	140737352475120
rcx	0x7ffff6ca5870	140737333844080
rdx	0x0	0
rsi	0x7ffff6f7a9d0	140737336814032
rdi	0x7ffff6f791c0	140737336807872
rbp	0x7fffffff9e30	140737488330288
rsp	0x7fffffff9d70	140737488330096
r8	0x7ffff7fdf7c0	140737354004416
r9	0x6372732f736a2f6c	7165916604736876396
r10	0x7fffffff9b30	140737488329520
r11	0x7ffff6c27ee0	140737333329632
r12	0x7fffffffa090	140737488330896
r13	0x7fffffff9dc0	140737488330176
r14	0x7fffffff9de0	140737488330208
r15	0x7ffff6907800	140737330051072
rip	0x63a02b <js::SetNameOperation(JSContext*, JSScript*, unsigned char*, JS::Handle<JSObject*>, JS::Handle<JS::Value>)+859>
=> 0x63a02b <js::SetNameOperation(JSContext*, JSScript*, unsigned char*, JS::Handle<JSObject*>, JS::Handle<JS::Value>)+859>:	movl   $0x119,0x0
   0x63a036 <js::SetNameOperation(JSContext*, JSScript*, unsigned char*, JS::Handle<JSObject*>, JS::Handle<JS::Value>)+870>:	callq  0x4a6780 <abort()>
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/f19fec531e71
user:        Shu-yu Guo
date:        Sun Jun 21 11:49:57 2015 -0700
summary:     Bug 1165486 - Replace the PlainObj varobj with NonSyntacticVariablesObject. (r=luke)

This iteration took 212.805 seconds to run.
Shu-yu, is bug 1165486 a likely regressor?
Blocks: 1165486
Flags: needinfo?(shu)
Apparently we just never handled this case.
Attachment #8727675 - Flags: review?(jorendorff)
Flags: needinfo?(shu)
Comment on attachment 8727675 [details] [diff] [review]
Handle DebugScopeProxies around unqualified varobjs in setname.

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

Clearing review because efaust says Ion's SETNAME IC might need to be fixed too.
Attachment #8727675 - Flags: review?(jorendorff)
ni myself to go back and investigate this with shu, so we can get this moving again
Flags: needinfo?(efaustbmo)
The bug in this case arises when trying to do a strict SETNAME with a
DebugScopeProxy on the scope chain, which should only happen for Debugger eval
frames. Debugger eval frames are never Ion-compiled, so Ion ICs don't need to
be fixed. Baseline ICs look fine.

I did simplify the test though.
Attachment #8732467 - Flags: review?(jorendorff)
Attachment #8727675 - Attachment is obsolete: true
Attachment #8732467 - Flags: review?(jorendorff) → review+
(In reply to Shu-yu Guo [:shu] from comment #6)
> The bug in this case arises when trying to do a strict SETNAME with a
> DebugScopeProxy on the scope chain, which should only happen for Debugger
> eval
> frames. Debugger eval frames are never Ion-compiled, so Ion ICs don't need to
> be fixed. Baseline ICs look fine.

Makes sense to me.
Flags: needinfo?(efaustbmo)
https://hg.mozilla.org/mozilla-central/rev/4ec87322b994
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Any hope of this getting on to at least mozilla-aurora as well?
Flags: needinfo?(shu)
Comment on attachment 8732467 [details] [diff] [review]
Handle DebugScopeProxies around unqualified varobjs in setname.

Approval Request Comment
[Feature/regressing bug #]: bug 1165486
[User impact if declined]: devtools debugger could crash when debugging chrome code in DEBUG builds, incorrect behavior in non-DEBUG builds.
[Describe test coverage new/current, TreeHerder]: on m-c
[Risks and why]: low; bug fix only.
[String/UUID change made/needed]: none
Flags: needinfo?(shu)
Attachment #8732467 - Flags: approval-mozilla-aurora?
Comment on attachment 8732467 [details] [diff] [review]
Handle DebugScopeProxies around unqualified varobjs in setname.

Crash fix, Aurora47+
Attachment #8732467 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.