1406879 - Crash [@ js::jit::ScriptFromCalleeToken] or Assertion failure: hasJSExitFP(), at vm/Stack.h:1566

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P2)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 8dba4037f395 (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-stdcxx-compat --disable-profiling --disable-debug --without-intl-api --enable-optimize --target=i686-pc-linux-gnu --enable-simulator=arm, run with --fuzzing-safe --ion-eager):

var lfModule = new WebAssembly.Module(wasmTextToBinary(`
    (module
        (import "global" "func" (result i32))
        (func (export "func_0") (result i32)
         call 0 ;; calls the import, which is func #0
        )
    )
`));
processModule(lfModule, `
enableGeckoProfiling();
try {
  enableSingleStepProfiling();
} catch (e) {}
`);
function processModule(module, jscode) {
    imports = {}
    for (let descriptor of WebAssembly.Module.imports(module)) {
        imports[descriptor.module] = {}
        imports[descriptor.module][descriptor.name] = new Function("x", "y", "z", jscode);
        try {
            instance = new WebAssembly.Instance(module, imports);
        } catch (exc) {}
    }
    for (let descriptor of WebAssembly.Module.exports(module)) {
        print(instance.exports[descriptor.name]())
    }
}


Backtrace:

received signal SIGSEGV, Segmentation fault.
0x0829c7d3 in js::jit::ScriptFromCalleeToken (token=0x9cf50b60) at js/src/jit/JitFrames.h:88
#0  0x0829c7d3 in js::jit::ScriptFromCalleeToken (token=0x9cf50b60) at js/src/jit/JitFrames.h:88
#1  js::jit::JSJitProfilingFrameIterator::frameScript (this=0xffffb54c) at js/src/jit/JSJitFrameIter-inl.h:57
#2  js::jit::JSJitProfilingFrameIterator::tryInitWithPC (this=0xffffb54c, pc=0x0) at js/src/jit/JSJitFrameIter.cpp:537
#3  0x0829c9d1 in js::jit::JSJitProfilingFrameIterator::JSJitProfilingFrameIterator (this=0xffffb54c, cx=0xf791d000, state=...) at js/src/jit/JSJitFrameIter.cpp:494
#4  0x085f22e0 in JS::ProfilingFrameIterator::iteratorConstruct (this=0xffffb53c, state=...) at js/src/vm/Stack.cpp:1946
#5  0x085f2a26 in JS::ProfilingFrameIterator::ProfilingFrameIterator (this=0xffffb53c, cx=0xf791d000, state=..., sampleBufferGen=4294967295) at js/src/vm/Stack.cpp:1874
#6  0x08099786 in SingleStepCallback (arg=0xf791d000, sim=<optimized out>, pc=<optimized out>) at js/src/shell/js.cpp:5309
#7  0x083e40aa in js::jit::Simulator::execute<false> (this=0xf7942000) at js/src/jit/arm/Simulator-arm.cpp:4862
#8  js::jit::Simulator::callInternal (this=0xf7942000, entry=0x462ba278 "\004\340-\345\360\037-\351\020\212", <incomplete sequence \355>) at js/src/jit/arm/Simulator-arm.cpp:4935
#9  0x083e4147 in js::jit::Simulator::call (this=<optimized out>, entry=<optimized out>, argument_count=<optimized out>) at js/src/jit/arm/Simulator-arm.cpp:5018
#10 0x086dc980 in js::wasm::Instance::callExport (this=0xf51727c0, cx=0xf791d000, funcIndex=1, args=...) at js/src/wasm/WasmInstance.cpp:681
#11 0x086dd0a5 in WasmCall (cx=0xf791d000, argc=0, vp=0xf55ffd58) at js/src/wasm/WasmJS.cpp:1164
#12 0x0815443a in js::CallJSNative (args=..., native=<optimized out>, cx=0xf791d000) at js/src/jscntxtinlines.h:293
[...]
#47 main (argc=4, argv=0xffffcdf4, envp=0xffffce08) at js/src/shell/js.cpp:8736
eax	0x9cf50b60	-1661662368
ebx	0x0	0
ecx	0x0	0
edx	0xffffb54c	-19124
esi	0x8acdff4	145547252
edi	0x0	0
ebp	0xf51e95d0	4112422352
esp	0xffffb45c	4294947932
eip	0x829c7d3 <js::jit::JSJitProfilingFrameIterator::tryInitWithPC(void*)+83>
=> 0x829c7d3 <js::jit::JSJitProfilingFrameIterator::tryInitWithPC(void*)+83>:	mov    0x14(%eax),%eax
   0x829c7d6 <js::jit::JSJitProfilingFrameIterator::tryInitWithPC(void*)+86>:	mov    0x14(%eax),%ecx


Marking s-s because this crashes with a non-null crash in a release build on ARM. On debug builds, it asserts on all architectures, so I'm not sure what effect enableSingleStepProfiling has (which is ARM only afaik).

Comment 1

[Benjamin Bouvier [:bbouvier] (inactive)]

Almost sure that's a fallout from bug 1360211. Will investigate.

Comment 2

[Benjamin Bouvier [:bbouvier] (inactive)]

Attachment: skipwasmframes.patch

When enabling the gecko profiler, we set the virtual JS jit FP (lastProfilingFrame) for each jit activation that might be running jit code. I totally missed there could be wasm frames on these activations, so this patch just skips them with a *regular* iterator, before passing the value of the JSJit fp to a *profiling* iterator as done before.

Also, I don't think this would need sec-approval, since this is trunk only.

Comment 3

[Jan de Mooij [:jandem]]

Comment on attachment 8917355 [details] [diff] [review]
skipwasmframes.patch

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

Makes sense.

::: js/src/vm/GeckoProfiler.cpp
@@ +70,5 @@
>          return nullptr;
>  
> +    jit::JitActivation* jitActivation = act->asJit();
> +
> +    // If there is not exit frame set, just return.

Nit: s/not/no/ ?

Comment 4

[Benjamin Bouvier [:bbouvier] (inactive)]

Thanks! Landed since it's trunk only.

https://hg.mozilla.org/integration/mozilla-inbound/rev/df8f9a0ccc91adf71e23280b5eefd7d3b6064b04

Comment 5

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/df8f9a0ccc91