Closed Bug 1451382 Opened 6 years ago Closed 6 years ago

Crash [@ ??] with Debugger on ARM64

Categories

(Core :: JavaScript Engine, defect, P3)

ARM64
Linux
defect

Tracking

()

RESOLVED DUPLICATE of bug 1446307
Tracking Status
firefox61 --- wontfix

People

(Reporter: decoder, Unassigned)

References

(Blocks 1 open bug)

Details

(4 keywords, Whiteboard: [jsbugmon:update,bisect])

Crash Data

The following testcase crashes on mozilla-central revision 5ec55f7a95f9 (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --enable-debug, run with --fuzzing-safe):

var g = newGlobal();
var dbg = Debugger(g);

function loop(i) {
    var n = 0;
    for (n = 0; n < i; n++) debugger;
}
g.eval(loop.toSource());
var countDown = 20;
dbg.onDebuggerStatement = function(f) {};
g.eval("loop(" + (2 * countDown) + ");");


Backtrace:

received signal SIGILL, Illegal instruction.
0x0000074735090d14 in ?? ()
#0  0x0000074735090d14 in ?? ()
#1  0x0000000000554ac4 in Interpret (cx=0xffffffffcc20, state=...) at js/src/vm/Interpreter.cpp:2037
#2  0x0000000000555228 in js::RunScript (cx=0xffffb6e16000, state=...) at js/src/vm/Interpreter.cpp:417
#3  0x0000000000558008 in js::ExecuteKernel (cx=<optimized out>, script=..., script@entry=..., envChainArg=..., newTargetValue=..., evalInFrame=..., evalInFrame@entry=..., result=<optimized out>) at js/src/vm/Interpreter.cpp:700
#4  0x000000000058c418 in EvalKernel (cx=<optimized out>, cx@entry=0xffffb6e16000, v=..., evalType=evalType@entry=INDIRECT_EVAL, caller=..., env=env@entry=..., pc=pc@entry=0x0, vp=...) at js/src/builtin/Eval.cpp:323
#5  0x000000000058c9a4 in js::IndirectEval (cx=0xffffb6e16000, argc=<optimized out>, vp=<optimized out>) at js/src/builtin/Eval.cpp:416
#6  0x0000000000560740 in js::CallJSNative (cx=0xffffb6e16000, native=native@entry=0x58c8b0 <js::IndirectEval(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/vm/JSContext-inl.h:290
#7  0x00000000005556b0 in js::InternalCallOrConstruct (cx=<optimized out>, cx@entry=0xffffb6e16000, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:467
#8  0x0000000000555a28 in InternalCall (cx=cx@entry=0xffffb6e16000, args=...) at js/src/vm/Interpreter.cpp:516
#9  0x0000000000555b98 in js::Call (cx=cx@entry=0xffffb6e16000, fval=..., fval@entry=..., thisv=..., args=..., rval=...) at js/src/vm/Interpreter.cpp:535
#10 0x00000000009cde8c in js::ForwardingProxyHandler::call (this=this@entry=0x12ca8d0 <js::CrossCompartmentWrapper::singleton>, cx=0xffffb6e16000, proxy=..., proxy@entry=..., args=...) at js/src/proxy/Wrapper.cpp:176
#11 0x00000000009bb914 in js::CrossCompartmentWrapper::call (this=0x12ca8d0 <js::CrossCompartmentWrapper::singleton>, cx=<optimized out>, wrapper=..., args=...) at js/src/proxy/CrossCompartmentWrapper.cpp:358
#12 0x00000000009b9698 in js::Proxy::call (cx=0xffffb6e16000, proxy=proxy@entry=..., args=...) at js/src/proxy/Proxy.cpp:510
#13 0x00000000009b9764 in js::proxy_Call (cx=<optimized out>, argc=<optimized out>, vp=<optimized out>) at js/src/proxy/Proxy.cpp:769
#14 0x0000000000560740 in js::CallJSNative (cx=0xffffb6e16000, native=0x9b96d8 <js::proxy_Call(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/vm/JSContext-inl.h:290
#15 0x0000000000555964 in js::InternalCallOrConstruct (cx=<optimized out>, cx@entry=0xffffb6e16000, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:449
#16 0x0000000000555a28 in InternalCall (cx=0xffffb6e16000, args=...) at js/src/vm/Interpreter.cpp:516
#17 0x0000000000549ea4 in js::CallFromStack (args=..., cx=<optimized out>) at js/src/vm/Interpreter.cpp:522
#18 Interpret (cx=0xffffb6e16000, state=...) at js/src/vm/Interpreter.cpp:3084
#19 0x0000000000555228 in js::RunScript (cx=0xffffb6e16000, state=...) at js/src/vm/Interpreter.cpp:417
[...]
#28 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at js/src/shell/js.cpp:9137
x0	0x1	1
x1	0x0	0
x2	0x8a9d1300	-1903715080208575744
x3	0xffffc5a8	281474976695720
x4	0x6	6
x5	0x0	0
x6	0xb6018190	281473735295376
x7	0xffffc9aa	281474976696746
x8	0xffffc9aa	281474976696746
x9	0x1c	28
x10	0x10f0	4336
x11	0x1010	4112
x12	0x11b0	4528
x13	0x1010	4112
x14	0x11d8	4568
x15	0x1010	4112
x16	0x12d0250	19726928
x17	0xb7fb0fb0	281473768427440
x18	0x1348	4936
x19	0x35090d14	8002413858068
x20	0xb6e16000	281473749966848
x21	0xffffcc38	281474976697400
x22	0xffffcca0	281474976697504
x23	0xffffc9d8	281474976696792
x24	0x14c	4294967628
x25	0xffffccb0	281474976697520
x26	0xffffcc08	281474976697352
x27	0xffffcc20	281474976697376
x28	0xffffc9a8	281474976696744
x29	0xffffcb70	281474976697200
x30	0x610044	6357060
sp	0xffffc980	281474976696704
pc	0x35090d14	8002413858068
cpsr	0x0	0
fpcsr	void
fpcr	0x0	0
=> 0x74735090d14:	.inst	0xffff006c ; undefined
   0x74735090d18:	cbnz	w16, 0x747350a2b28


This doesn't reproduce in simulator, the hardware used is an ARMv8 Cavium ThunderX SoC.
Lars?
Flags: needinfo?(lhansen)
I think we want to fix bug 1446307 before we worry too much about this one; if that turns out to be some cache flushing issue then that could easily be the root cause here as well.
Flags: needinfo?(lhansen)
Priority: -- → P3
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
No crashes with this signature in the last month.
You need to log in before you can comment on or make changes to this bug.