1873592 - Crash in [@ WarpScriptOracle::getICEntryAndFallback]

Status: RESOLVED INVALID

(Core :: JavaScript Engine: JIT, defect, P3)

Description

[Paul Bone [:pbone]]

Crash report: https://crash-stats.mozilla.org/report/index/1412f1da-f258-4fe4-982e-649550240107

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0  xul.dll  WarpScriptOracle::getICEntryAndFallback  js/src/jit/WarpOracle.cpp:256
0  xul.dll  WarpScriptOracle::maybeInlineIC  js/src/jit/WarpOracle.cpp:773
0  xul.dll  WarpScriptOracle::createScriptSnapshot  js/src/jit/WarpOracle.cpp:589
1  xul.dll  js::jit::WarpOracle::createSnapshot  js/src/jit/WarpOracle.cpp:159
1  xul.dll  js::jit::CreateWarpSnapshot  js/src/jit/Ion.cpp:1597
1  xul.dll  js::jit::IonCompile  js/src/jit/Ion.cpp:1667
1  xul.dll  js::jit::Compile  js/src/jit/Ion.cpp:1860
2  xul.dll  BaselineCanEnterAtEntry  js/src/jit/Ion.cpp:1992
2  xul.dll  IonCompileScriptForBaseline  js/src/jit/Ion.cpp:2117
2  xul.dll  js::jit::IonCompileScriptForBaselineAtEntry  js/src/jit/Ion.cpp:2144

This is a PHC buffer overflow. The PHC allocation stack is:

#0 JSScript::createJitScript(JSContext*) (xul.dll)
#1 js::jit::BaselineCompiler::compile() (xul.dll)
#2 js::jit::BaselineCompile(JSContext*, JSScript*, bool) (xul.dll)
#3 js::jit::MaybeEnterJit(JSContext*, js::RunState&) (xul.dll)
#4 js::jit::DoCallFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICFallbackStub*, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) (xul.dll)
#5 ??? (firefox.exe)

The crashing address is: 0x00000219163da008, 8 bytes beyond the end of the 1536 byte object allocated at: 0x219163d9a00

Comment 1

[Nicolas B. Pierron [:nbp] {away}]

Having the allocation site is quite useful, in the current case this is a dereference of an post-structure inline array element which seems to trip over the allocation monitored by PHC.

PHC ensures that a few allocation are allocated next to page boundaries and relies on the system with the use of guard pages to report when an error occurs.

This could potentially be an off-by-1 in the counting of fallback IC or a memory-issue in the RAM.

Jan, can you investigate this issue?

Comment 2

[Iain Ireland [:iain]]

In getICEntryAndFallback, we increment the icEntryIndex until we find a fallback stub with the correct offset:

  const uint32_t offset = loc.bytecodeToOffset(script_);

  do {
    *fallback = icScript_->fallbackStub(icEntryIndex_);
    icEntryIndex_++;
  } while ((*fallback)->pcOffset() < offset);

If something is corrupted (for example, if loc.bytecodeToOffset() returns a bogus offset that is too big), then we will keep reading past the end of the fallback stubs, which are at the end of the ICScript allocation. I think that would show up exactly here. (Maybe we should have crashed when we tried reading 0x00000219163da000, the word immediately following the fallback stubs array?)

I can't think of an explanation for this crash that doesn't involve corrupted memory somehow. We're being called from maybeInlineIC, which should have a valid bytecode location. We initialize the fallback stubs in ICScript::initICEntries, and never modify them after that. This code is very hot, and there aren't many places for a bug to be hiding.

I lean towards thinking this is a hardware issue, not a real bug. I'll let Jan weigh in before opening it up, though.

Comment 3

[Gabriele Svelto [:gsvelto]]

(In reply to Iain Ireland [:iain] from comment #2)

I lean towards thinking this is a hardware issue, not a real bug. I'll let Jan weigh in before opening it up, though.

Yes, note that the crash address has been detected as a potential bit-flip and there's a couple more under this signature.

Comment 4

[Jan de Mooij [:jandem]]

(In reply to Iain Ireland [:iain] from comment #2)

I lean towards thinking this is a hardware issue, not a real bug. I'll let Jan weigh in before opening it up, though.

Agreed.

I was wondering if it could be related to inlined ICScripts because we had some regressions there, but the allocation stack suggests it's the main ICScript so that should be unrelated.

Comment 5

[Jan de Mooij [:jandem]]

Opening this up given it looks like a hardware issue.

Comment 6

[Andrew McCreight [:mccr8]]

I'll close this as invalid if there is no actual Firefox bug here. (Invalid seems like the most accurate designation to me but feel free to change it to something better.)