1526543 - Assertion failure: !used(), at js/src/jit/Label.h:85 with --dump-bytecode

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

I still see this assertion failure on mozilla-central revision b482c6618d72 on 32-bit ARM simulator (hard to reproduce):

Backtrace:

#0 js::jit::Label::~Label (this=0x1eb9) at js/src/jit/Label.h:85
#1 GenerateImportJitExit (masm=..., fi=..., funcImportIndex=5, offsets=0xda4, throwLabel=<optimized out>) at js/src/wasm/WasmStubs.cpp:1690
#2 js::wasm::GenerateStubs (env=..., imports=..., exports=..., code=0xf0814170) at js/src/wasm/WasmStubs.cpp:2179
#3 0x582c6112 in js::wasm::ModuleGenerator::finishCodeTier (this=0xffbf3fa8) at js/src/wasm/WasmGenerator.cpp:999
#4 0x582c6db8 in js::wasm::ModuleGenerator::finishModule (this=0xffbf3fa8, bytecode=..., maybeTier2Listener=0x0, maybeLinkData=0x0) at js/src/wasm/WasmGenerator.cpp:1098
#5 0x5824c35b in js::wasm::CompileBuffer (args=..., bytecode=..., error=0xffbf4ab8, warnings=0xffbf4a60, maybeLinkData=0x0) at js/src/wasm/WasmCompile.cpp:578
#6 0x582e6ea3 in js::WasmModuleObject::construct (cx=<optimized out>, argc=1, vp=0xf6bf3080) at js/src/wasm/WasmJS.cpp:1109
/snip

For detailed crash information, see attachment.

Comment 1

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: Detailed Crash Information

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Setting needinfo? from Arai-san. Arai-san was working on the possibly-related bug 1519037 previously.

Comment 3

[Fuzzing Team]

JSBugMon: Cannot process bug: Error: Failed to isolate test from comment

Comment 4

[Tooru Fujisawa [:arai]]

Checked about the backtrace locally, with the same JS shell binary,
with GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git.
running with --fuzzing-safe --no-threads --ion-eager --gc-zeal=19,251 --dump-bytecode w104-out.wrapper w104-out.wasm

for me, gdb points wrong value for this inside Label::~Label frame,
it's not this pointer value but *(intptr_t*)this that is this->bound_ | (this->offset_ << 1).

but I don't observe this=0x1eb9, it becomes 0x2b1, 0x649, 0x991, 0xcc9, and 0x1059 (seems to be consistent across multiple run)

while the value is different, if the same thing is happening in printing backtrace there,
this=0x1eb9 would actually mean this->bound_ = 1 and this->offset_ = 0xf5c,
and in that case Label::used() is false, because bound() is true.

https://searchfox.org/mozilla-central/rev/03ebbdab952409640c6857d835d3040bf6f9e2db/js/src/jit/Label.h#37-43

struct LabelBase {
  // We use uint32_t instead of bool to ensure MSVC packs these fields
  // correctly.
  uint32_t bound_ : 1;

  // offset_ < INVALID_OFFSET means that the label is either bound or has
  // incoming uses and needs to be bound.
  uint32_t offset_ : 31;

...

  static const uint32_t INVALID_OFFSET = 0x7fffffff;  // UINT31_MAX.

...

  // If the label is bound, all incoming edges have been patched and any
  // future incoming edges will be immediately patched.
  bool bound() const { return bound_; }
  int32_t offset() const {
    MOZ_ASSERT(bound() || used());
    return offset_;
  }
  // Returns whether the label is not bound, but has incoming uses.
  bool used() const { return !bound() && offset_ < INVALID_OFFSET; }

and the assertion doesn't fail for the condition.

https://searchfox.org/mozilla-central/rev/03ebbdab952409640c6857d835d3040bf6f9e2db/js/src/jit/Label.h#85

class Label : public LabelBase {
 public:
  ~Label() {
#ifdef DEBUG
    // The assertion below doesn't hold if an error occurred.
    JitContext* context = MaybeGetJitContext();
    bool hadError =
        js::oom::HadSimulatedOOM() ||
        (context && context->runtime && context->runtime->hadOutOfMemory());
    MOZ_ASSERT_IF(!hadError, !used());

what I can think of is, one of:

• the algorithm used by determining this value is different than local gdb run
• some stack corruption happened (maybe after checking condition?) and the this value printed there is something different than *(intptr_t*)this
• execution somehow jumps there unexpectedly

Comment 5

[Tooru Fujisawa [:arai]]

just to be sure, is the running parameter in comment #4 correct?
also, do you know how the backtrace is printed?

Comment 6

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

1. I think so? I can't seem to find the old testcase now..
2. The backtrace is printed using the commands here:

https://github.com/MozillaSecurity/funfuzz/blob/4d66cd8/src/funfuzz/util/gdb_cmds.txt

3. I enabled a run over the weekend with --disable-optimize and --dump-bytecode mostly turned on, but they still haven't showed anything with this assertion.

Comment 7

[Tooru Fujisawa [:arai]]

(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #6)

2. The backtrace is printed using the commands here:

https://github.com/MozillaSecurity/funfuzz/blob/4d66cd8/src/funfuzz/util/gdb_cmds.txt

Thanks, so it's also using gdb, and what I observed about this value calculation should be almost same as what happens there.

3. I enabled a run over the weekend with --disable-optimize and --dump-bytecode mostly turned on, but they still haven't showed anything with this assertion.

if it happens only on opt build, it might be caused by UB...

if it takes a lot of time to run the test and that decreases the chance to hit the issue,
using --code-coverage instead might help, that enables profiling part only, and bytecode dumping part will be skipped (that I think takes a lot more time)

Comment 8

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

I've now started a run with --code-coverage instead of --dump-bytecode and made the --enable-optimize/--disable-optimize probabilities to be 50/50.

Comment 9

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(these past 3 days I don't think I've really seen any of these asserts, but I'll probably wait till next week to say more)

Comment 10

[Neha Kochar [:neha]]

Gary, came across this when tracking 67 regressions. Do you still see these asserts or are these all gone now?

Comment 11

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Unsure, I was testing with the new set of --code-coverage flags and --enable-optimize/--disable-optimize as 50/50 probabilities, which I haven't seen anymore of these.

I'll need to next switch back to --dump-bytecode.

Comment 12

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Switched back and reduced --disable-optimize possibilities to 10%. Will see what happens in the upcoming week.

Comment 13

[Andrew Overholt [:overholt]]

(In reply to Gary Kwong [:gkw] [:nth10sd] - gradually taking PTO-ish till Mar 11 from comment #12)

Switched back and reduced --disable-optimize possibilities to 10%. Will see what happens in the upcoming week.

Hey Gary, I know it's not quite a week but given your increasing PTO we wanted to catch you before you were out :) Did anything change in the past 6.75 days?

Comment 14

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

I don't think so, it seems to have gone away. Let's mark this WFM and then we'll see what happens next.