951573 - Assertion failure: (uint32_t)(const uint32_t *)val == uint32_t(expectedValue.value), at jit/arm/Assembler-arm.cpp

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, defect)

Description

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

Attachment: stack

s = []
for (var j = 0; j < 999999; j++) {}

asserts js debug shell on m-c changeset 862cb6a1cc88 without any CLI arguments at Assertion failure: (uint32_t)(const uint32_t *)val == uint32_t(expectedValue.value), at jit/arm/Assembler-arm.cpp

My configure flags are:

CC="gcc -mfloat-abi=softfp -B/usr/lib/gcc/arm-linux-gnueabi/4.7" AR=ar CXX="g++ -mfloat-abi=softfp -B/usr/lib/gcc/arm-linux-gnueabi/4.7" sh ./configure --target=arm-linux-gnueabi --enable-optimize --enable-debug --enable-profiling --enable-gczeal --enable-debug-symbols --enable-methodjit --enable-type-inference --disable-tests --enable-more-deterministic --with-ccache --enable-threadsafe <other NSPR options>


autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   http://hg.mozilla.org/mozilla-central/rev/9db2450f2a16
user:        Hannes Verschore
date:        Wed Sep 18 17:53:41 2013 +0200
summary:     Bug 910960 - IonMonkey: Improve codegen of TypeBarriers, r=nbp

Hannes, is bug 910960 a likely regressor?

Comment 1

[Hannes Verschore [:h4writer]]

The place it is failing, cannot be introduced by Bug 910960. (Though I didn't try to debug myself. This is solely based on the data in comment 0).

Comment 2

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

(In reply to Hannes Verschore [:h4writer] from comment #1)
> The place it is failing, cannot be introduced by Bug 910960. (Though I
> didn't try to debug myself. This is solely based on the data in comment 0).

In that case, we need some ARM folks to take a look - it's occurring very often on ARM.

Comment 4

[Marty Rosenberg [:mjrosenb]]

Attachment: updateIonScriptLabels-r0.patch

Comment 5

[Jan de Mooij [:jandem]]

Comment on attachment 8349312 [details] [diff] [review]
updateIonScriptLabels-r0.patch

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

Oops, thanks!

Comment 6

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

Marty, does this bug affect other branches? (it might need sec-approval, for that matter)

Comment 7

[Marty Rosenberg [:mjrosenb]]

it probably isn't a big deal.  The added code that is causing this failure is:
      jdemooij 1b91cf5c8407:  #ifdef DEBUG
      jdemooij 1b91cf5c8407:      for (size_t i = 0; i < ionScriptLabels_.length(); i++) {
    mrosenberg 440213a072ac:          ionScriptLabels_[i].fixup(&masm);
      jdemooij 1b91cf5c8407:          Assembler::patchDataWithValueCheck(CodeLocationLabel(code, ionScriptLabels_[i]),
      jdemooij 1b91cf5c8407:                                             ImmPtr(ionScript),
      jdemooij 1b91cf5c8407:                                             ImmPtr((void*)-1));
      jdemooij 1b91cf5c8407:      }
      jdemooij 1b91cf5c8407:  #endif
 which was landed on the 14th, and is actually only active in debug builds, so it isn't that there is a bad patch that is only guarded in debug builds, the relevant code only exists in debug builds.

Comment 8

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/e4d49705cdfe

Helping to land since this seems to affect only m-c as per comment 7. Thanks!

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Backed out for Win7 debug xpcshell orange.
https://hg.mozilla.org/integration/mozilla-inbound/rev/343f2a3934ef

https://tbpl.mozilla.org/php/getParsedLog.php?id=32177582&tree=Mozilla-Inbound

Comment 10

[Ryan VanderMeulen [:RyanVM]]

This wasn't at fault. Relanded.
https://hg.mozilla.org/integration/mozilla-inbound/rev/14eaffaa838a

Comment 11

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/14eaffaa838a

Comment 12

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Marking b2g affected-ness based on comment 7.