959126 - Crash in js::jit::LiveInterval::start

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine: JIT, defect)

Description

[:gerard-majax]

While trying to reproduce bug 956325, I hit this.

(gdb) bt
#0  0x41bbfd24 in js::jit::LiveInterval::start (this=0xbefb8348) at /home/alex/codaz/Mozilla/b2g/devices/Inari/B2G/gecko/js/src/jit/LiveRangeAllocator.h:267
#1  js::jit::LiveRangeAllocator<js::jit::LinearScanVirtualRegister, true>::findFirstSafepoint (this=0xbefb8348) at /home/alex/codaz/Mozilla/b2g/devices/Inari/B2G/gecko/js/src/jit/LiveRangeAllocator.h:721
#2  js::jit::LinearScanAllocator::populateSafepoints (this=0xbefb8348) at /home/alex/codaz/Mozilla/b2g/devices/Inari/B2G/gecko/js/src/jit/LinearScan.cpp:499
#3  0x41bc3bc4 in js::jit::LinearScanAllocator::go (this=0xbefb8348) at /home/alex/codaz/Mozilla/b2g/devices/Inari/B2G/gecko/js/src/jit/LinearScan.cpp:1272
#4  0x41b574d4 in js::jit::GenerateLIR (mir=0x4635d0e8) at /home/alex/codaz/Mozilla/b2g/devices/Inari/B2G/gecko/js/src/jit/Ion.cpp:1436
#5  0x41b576d6 in js::jit::CompileBackEnd (mir=0x4635d0e8, maybeMasm=0x0) at /home/alex/codaz/Mozilla/b2g/devices/Inari/B2G/gecko/js/src/jit/Ion.cpp:1527
#6  0x41b5e178 in IonCompile (cx=0x403ca8e0, script=..., osrFrame=<value optimized out>, osrPc=0x0, constructing=<value optimized out>, executionMode=js::SequentialExecution)
    at /home/alex/codaz/Mozilla/b2g/devices/Inari/B2G/gecko/js/src/jit/Ion.cpp:1776
#7  Compile (cx=0x403ca8e0, script=..., osrFrame=<value optimized out>, osrPc=0x0, constructing=<value optimized out>, executionMode=js::SequentialExecution)
    at /home/alex/codaz/Mozilla/b2g/devices/Inari/B2G/gecko/js/src/jit/Ion.cpp:1979
#8  0x41b5e924 in js::jit::CanEnter (cx=0x403ca8e0, state=...) at /home/alex/codaz/Mozilla/b2g/devices/Inari/B2G/gecko/js/src/jit/Ion.cpp:2117
#9  0x41db9fc8 in js::RunScript (cx=0x403ca8e0, state=...) at /home/alex/codaz/Mozilla/b2g/devices/Inari/B2G/gecko/js/src/vm/Interpreter.cpp:397
#10 0x41dba4da in js::Invoke (cx=0x403ca8e0, args=..., construct=js::NO_CONSTRUCT) at /home/alex/codaz/Mozilla/b2g/devices/Inari/B2G/gecko/js/src/vm/Interpreter.cpp:484
#11 0x41cae992 in js_fun_call (cx=0x403ca8e0, argc=1, vp=0xbefb8af8) at /home/alex/codaz/Mozilla/b2g/devices/Inari/B2G/gecko/js/src/jsfun.cpp:910
#12 0x435db2f0 in ?? ()
#13 0x435db2f0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

As far as Nicolas could look, this seems to happen on a Facebook script:
(gdb) p *fval.ptr.toObject().as<JSFunction>().u.i.s.script_->scriptSource()
$16 = {data = {
    source = 0x47722000 u"/*1389609465,182062685,JIT Construction: v1076786,en_US*/\n\n/**\n * Copyright Facebook Inc.\n *\n * Licensed under the Apache License, Version 2.0\n * http://www.apache.org/licenses/LICENSE-2.0\n */\ntry {wi"..., compressed = 0x47722000 "/"}, refs = 1, length_ = 175909, compressedLength_ = 0, filename_ = 0x44dc01a0 "http://connect.facebook.net/en_US/all.js#xfbml=1&appId=435462409848844", 
  displayURL_ = 0x0, sourceMapURL_ = 0x0, originPrincipals_ = 0x4579f064, sourceRetrievable_ = false, argumentsNotIncluded_ = false, ready_ = true}
(gdb) p fval.ptr.toObject().as<JSFunction>().u.i.s.script_->lineno_
$17 = 15
(gdb) p fval.ptr.toObject().as<JSFunction>().u.i.s.script_->column_
$18 = 132

This happened on an Inari debug build from today, with gdb attached to the "Communications" app process, while performing FTU: loading privacy pages.

Comment 1

[:gerard-majax]

As far as nicolas could check, ins was 0x0.

Comment 2

[:gerard-majax]

FYI, Gecko at 12dd20e and Gaia at 5ff5169.

Comment 3

[Preeti Raghunath(:Preeti)]

Naveed,

Please review from JS engine perspective.

Comment 4

[Jan de Mooij [:jandem]]

Nicolas, are you able to reproduce/bisect/debug this?

Comment 5

[Nicolas B. Pierron [:nbp]]

I tried to reproduce it on an Unagi after landing Bug 957475 but I did not managed to reproduce it.
Alexandre tried with the patch of Bug 957475 on an Inari before and this solve the issue.

Alexandre, are you still seeing this issue (or the original one) with the latest version of Gecko?  Otherwise we should mark this one as a duplicate.

Comment 6

[:gerard-majax]

I think this has been fixed by another bug reported by gregor, but I cannot find it.

Comment 7

[Jan de Mooij [:jandem]]

Yes this was likely fixed.