Closed Bug 1261324 Opened 5 years ago Closed 5 years ago

Crash [@ callStackAtAddr] or Assertion failure: nativeStartAddr, at jit/JitcodeMap.h:164 with enableSingleStepProfiling and Debugger


(Core :: JavaScript Engine, defect)

Not set



Tracking Status
firefox48 --- fixed


(Reporter: decoder, Assigned: shu)


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

Crash Data


(1 file)

The following testcase crashes on mozilla-central revision 494289c72ba3 (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --target=i686-pc-linux-gnu --disable-tests --enable-simulator=arm --disable-debug, run with --fuzzing-safe --no-threads):

g = newGlobal()
g.parent = this
g.eval("new Debugger(parent).onExceptionUnwind = function () {}")
function assertThrowsInstanceOf(f) {
    try {
    } catch (exc) {}
function testThrow(thunk) {
    for (i = 0;; i++) {
        iter = thunk()
        assertThrowsInstanceOf(function() iter.throw())
testThrow(function*() {})


Program received signal SIGSEGV, Segmentation fault.
callStackAtAddr (maxResults=64, results=0xffff9980, ptr=0x0, rt=0xf7a3c000, this=0xffff9950) at js/src/jit/JitcodeMap.h:793
#0  callStackAtAddr (maxResults=64, results=0xffff9980, ptr=0x0, rt=0xf7a3c000, this=0xffff9950) at js/src/jit/JitcodeMap.h:793
#1  JS::ProfilingFrameIterator::extractStack (this=this@entry=0xffff9b20, frames=frames@entry=0xffff9b50, offset=offset@entry=0, end=end@entry=16) at js/src/vm/Stack.cpp:1981
#2  0x0808bc2c in SingleStepCallback (arg=<optimized out>, sim=<optimized out>, pc=0x0) at js/src/shell/js.cpp:4562
#3  0x08355cf3 in execute<false> (this=0xf7a1c000) at js/src/jit/arm/Simulator-arm.cpp:4464
#4  js::jit::Simulator::callInternal (this=this@entry=0xf7a1c000, entry=entry@entry=0xf7fc8840 "\360O-\351\004\320M\342\020\212-\355\r\200\240\341h\220\235\345\r\260\240\341t\240\235", <incomplete sequence \345>) at js/src/jit/arm/Simulator-arm.cpp:4567
#5  0x08355eba in js::jit::Simulator::call (this=<optimized out>, entry=entry@entry=0xf7fc8840 "\360O-\351\004\320M\342\020\212-\355\r\200\240\341h\220\235\345\r\260\240\341t\240\235", <incomplete sequence \345>, argument_count=<optimized out>, argument_count@entry=8) at js/src/jit/arm/Simulator-arm.cpp:4650
#6  0x081638a0 in EnterBaseline (cx=cx@entry=0xf7a52040, data=...) at js/src/jit/BaselineJIT.cpp:150
#7  0x0816f959 in js::jit::EnterBaselineMethod (cx=cx@entry=0xf7a52040, state=...) at js/src/jit/BaselineJIT.cpp:188
#8  0x084d505b in js::RunScript (cx=cx@entry=0xf7a52040, state=...) at js/src/vm/Interpreter.cpp:416
#9  0x084d5202 in js::Invoke (cx=0xf7a52040, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:494
#10 0x084d563a in js::Invoke (cx=0xf7a52040, thisv=..., fval=..., argc=argc@entry=2, argv=argv@entry=0xffffa238, rval=rval@entry=...) at js/src/vm/Interpreter.cpp:528
#11 0x08459f62 in js::Debugger::fireExceptionUnwind (this=this@entry=0xf61ccc00, cx=0xf7a52040, vp=...) at js/src/vm/Debugger.cpp:1372
#12 0x0845a2a6 in operator() (dbg=0xf61ccc00, __closure=<synthetic pointer>) at js/src/vm/Debugger.cpp:781
#13 dispatchHook<js::Debugger::slowPathOnExceptionUnwind(JSContext*, js::AbstractFramePtr)::__lambda6, js::Debugger::slowPathOnExceptionUnwind(JSContext*, js::AbstractFramePtr)::__lambda7> (fireHook=..., cx=<optimized out>, hookIsEnabled=...) at js/src/vm/Debugger.cpp:1480
#14 js::Debugger::slowPathOnExceptionUnwind (cx=cx@entry=0xf7a52040, frame=...) at js/src/vm/Debugger.cpp:782
#15 0x081f90e7 in onExceptionUnwind (frame=..., cx=0xf7a52040) at js/src/vm/Debugger-inl.h:66
#16 HandleExceptionBaseline (pc=0xf61e8a56 "\320Q[", rfe=<optimized out>, frame=..., cx=<optimized out>) at js/src/jit/JitFrames.cpp:656
#17 js::jit::HandleException (rfe=0xf65ffac0) at js/src/jit/JitFrames.cpp:837
#18 0x08352971 in js::jit::Simulator::softwareInterrupt (this=0xf7a1c000, instr=0xf7a02674) at js/src/jit/arm/Simulator-arm.cpp:2340
#69 main (argc=4, argv=0xffffccf4, envp=0xffffcd08) at js/src/shell/js.cpp:7443
eax	0xf7a3c000	-140263424
ebx	0x94ab3e4	155890660
ecx	0x0	0
edx	0x0	0
esi	0xf7a1c000	-140394496
edi	0xffff9b20	-25824
ebp	0xffff9a98	4294941336
esp	0xffff9900	4294940928
eip	0x8513909 <JS::ProfilingFrameIterator::extractStack(JS::ProfilingFrameIterator::Frame*, unsigned int, unsigned int) const+249>
=> 0x8513909 <JS::ProfilingFrameIterator::extractStack(JS::ProfilingFrameIterator::Frame*, unsigned int, unsigned int) const+249>:	movl   $0x319,0x0
   0x8513913 <JS::ProfilingFrameIterator::extractStack(JS::ProfilingFrameIterator::Frame*, unsigned int, unsigned int) const+259>:	call   0x80912d0 <abort()>
This one was a doozy to debug. The bug is that if we sample during Debugger's
onExceptionUnwind, the 0x0 return addr pushed in [1] becomes observable to

I took the least-amount-of-typing route for this fix: if we have an override pc
on the BaselineFrame, convert that to a native address and and use that. I'm
pretty sure all cases where we set an override pc, that pc has/would generate
Baseline code.

This fix is slower than it needs to be: the round tripping of getting
nativeCodeForPC then re-looking up the PC via callStackAtAddr is stupid. That
said, to avoid the useless roundtrip requires threading the override pc through
various iterator, creating a new kind of entry in the JitcodeGlobalTable and is
in general a huge PITA.

My intuition is that this path should be rare enough that slowing down the
sampler here doesn't matter.

Attachment #8737448 - Flags: review?(jdemooij)
Assignee: nobody → shu
Comment on attachment 8737448 [details] [diff] [review]
Fix bogus return address for star generators' .throw being observed by the profiler in Debugger's onExceptionUnwind in Baseline.

Review of attachment 8737448 [details] [diff] [review]:

Thanks for fixing this!
Attachment #8737448 - Flags: review?(jdemooij) → review+
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
You need to log in before you can comment on or make changes to this bug.