866064 - Assertion failure: absolute_ && isSet(), at ion/shared/Assembler-shared.h

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

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

Attachment: stack

An extremely difficult to reproduce assertion is Assertion failure: absolute_ && isSet(), at ion/shared/Assembler-shared.h on a 32-bit debug deterministic threadsafe shell on Linux. I had to examine the core dump to get the stack.

This was on m-c changeset 1150403342b2. There are a couple of scary-looking addresses on the stack along with Baseline functions, so assuming this to be Baseline-related.

Comment 1

[Daniel Veditz [:dveditz]]

Is there enough information here to be useful or should this be closed incomplete? Without a testcase how is anyone going to investigate?

Comment 2

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

(In reply to Daniel Veditz [:dveditz] from comment #1)
> Is there enough information here to be useful or should this be closed
> incomplete? Without a testcase how is anyone going to investigate?

I was actually liaising with jandem offline (and providing him with testcases/coredumps) about this on Monday. Tuesday was a holiday for where he's from, so he'll probably get to it later.

Comment 3

[Jan de Mooij [:jandem]]

OK, Gary and I were able to track this down. The problem is that CodeOffsetLabel and CodeOffsetJump use the magic 0xdeadc0de value to mean "not set", see for instance:

    bool isSet() const {
        return raw_ != (uint8_t *) 0xdeadc0de;
    }

However, 0xdeadc0de is a perfectly valid address, so if we happen to allocate a label at that address isSet() will return |false| even though the label *is* set..

In this case we had code starting at 0xdeadbf88 and a label with offset 342, and 0xdeadbf88 + 342 == 0xdeadc0de.

Looking at all callers of isSet(), this is debug-only. We should fix it though to avoid rare test failures, etc.

Comment 4

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

Assigning to jandem since he knows what's going on.

Comment 5

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

jandem, any updates on this? I'm still seeing this intermittently with hard-to-reduce testcases.

Comment 6

[Jan de Mooij [:jandem]]

Attachment: Patch

CodeLocationLabel::raw_ and CodeLocationJump::raw_ can hold either a pointer or offset, so we can't use NULL either to mean "uninitialized". UINTPTR_MAX could work, but this patch uses an enum { Uninitialized, Absolute, Relative } instead.

Comment 7

[Nicolas B. Pierron [:nbp]]

Comment on attachment 774534 [details] [diff] [review]
Patch

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

Sounds good.

Comment 8

[Jan de Mooij [:jandem]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9db984a847ee

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/9db984a847ee