1496362 - Assertion failure: id == prev, at js/src/vm/TraceLogging.cpp:730

Status: RESOLVED FIXED

(Core :: JavaScript: WebAssembly, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 5675805eb31d (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --disable-profiling --enable-debug --enable-optimize, run with --fuzzing-safe --cpu-count=2 --ion-offthread-compile=off):

var lfLogBuffer = `
  Array.prototype[Symbol.iterator] = function*() { yield 1; yield 2; };
  setJitCompilerOption("jit.enable-tracelogger", 1);
  // Dummy
  // Dummy
  // Dummy
  // Dummy
  // Dummy
`;
lfLogBuffer = lfLogBuffer.split('\n');
var lfModule = new WebAssembly.Module(wasmTextToBinary(`(module)`));
var lfCodeBuffer = "";
while (true) {
    var line = lfLogBuffer.shift(); if (line == null) { break; }
    lfCodeBuffer += line + "\n";
}
processCode(lfCodeBuffer);
function processCode(lfVarx) {
    try { evaluate(lfVarx); } catch (lfVare) {}
    for (let descriptor of WebAssembly.Module.imports(lfModule)) {}
}


Backtrace:

received signal SIGSEGV, Segmentation fault.
0x000055555598fa49 in js::TraceLoggerThread::stopEvent (this=0x7ffff5412780, id=3) at js/src/vm/TraceLogging.cpp:730
#0  0x000055555598fa49 in js::TraceLoggerThread::stopEvent (this=0x7ffff5412780, id=3) at js/src/vm/TraceLogging.cpp:730
#1  0x0000134051e0f877 in ?? ()
[...]
#7  0x0000000000000000 in ?? ()
rax	0x0	0
rbx	0x7ffff5412780	140737308075904
rcx	0x7ffff6c1c2dd	140737333281501
rdx	0x0	0
rsi	0x7ffff6eeb770	140737336227696
rdi	0x7ffff6eea540	140737336223040
rbp	0x7fffffffc610	140737488340496
rsp	0x7fffffffc5f0	140737488340464
r8	0x7ffff6eeb770	140737336227696
r9	0x7ffff7fe6cc0	140737354034368
r10	0x58	88
r11	0x7ffff6b927a0	140737332717472
r12	0x3	3
r13	0x9	9
r14	0x1043	4163
r15	0x7ffff5434028	140737308213288
rip	0x55555598fa49 <js::TraceLoggerThread::stopEvent(unsigned int)+713>
=> 0x55555598fa49 <js::TraceLoggerThread::stopEvent(unsigned int)+713>:	movl   $0x0,0x0
   0x55555598fa54 <js::TraceLoggerThread::stopEvent(unsigned int)+724>:	ud2

Comment 1

[Benjamin Bouvier [:bbouvier] (inactive)]

It could just be that the tracelogger doesn't support wasm at the moment...

Comment 2

[Denis Palmeiro [:denispal]]

I didn't realize that the JitOptions could be changed directly within a test script.  I was intending on making the tracelogger behave the same way as it did before whenever activated from the shell: i.e. it must be invoked at startup.  So I think the proper fix here is to remove control of the "jit.enable-tracelogger" and "--enable-tracelogger" options and solely control the TL with environment variables when invoked from the shell.  The specific problem here is that the tracelogger is being activated in the middle of execution and we end up encountering a stopEvent for Baseline that doesn't match a startEvent which occurred before activation.

There is also a somewhat related error on line 676 of TraceLogging.cpp.  We need a p->release() after calling getPayload() or else the pointer counter will be incorrect.

Comment 3

[Denis Palmeiro [:denispal]]

Attachment: Limit control of tracelogger to only the gecko profiler and the previous environment variables implementation that triggers tracelogger only on startup.

Tracelogger is currently not setup to be toggled on and off while in the shell.  Removing access to the "jit.enable-tracelogger" will force the tracelogger to be invoked either through the new tracelogger API which is intended to be used by the profiler, or through setting the environment variables TLDIR, TLOPTIONS, and TLLOG.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/71160e8bcfb7
Limit control of tracelogger to only the gecko profiler and the previous environment variables implementation that triggers tracelogger only on startup. r=sfink

Comment 5

[Tiberius Oros[:tiberius_oros]]

https://hg.mozilla.org/mozilla-central/rev/71160e8bcfb7