1698609 - WrapOracle.cpp MOZ_ASSERT_IF(hash == oldHash, cx_->hadNondeterministicException());

Status: RESOLVED FIXED

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

Description

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

I've been reliably hitting https://searchfox.org/mozilla-central/rev/a848cde8a73065fcc41902ac58c65821eb9a44ca/js/src/jit/WarpOracle.cpp#188 while trying to debug a media issue. I'm not sure what prompted the problem, as it wasn't a permafail initially, but now is.

After playing the video on https://www.groovehq.com/watch-demo for ~2 seconds I trigger the assert on a local build built from cenrtral bd8121e747b5 (March 11).

Comment 1

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Commenting out the asserting code then triggers https://searchfox.org/mozilla-central/rev/a848cde8a73065fcc41902ac58c65821eb9a44ca/js/src/jit/JitScript.h#496 which makes it difficult to mitigate the issue in my debug builds.

Comment 2

[Matthew Gaudet (he/him) [:mgaudet]]

This is Iain's code; it's trying to catch potential performance issues, but we should have a flag (--disable-bailout-loop-checking or somesuch) to disable this for people like Bryce who can't action the resulting failure.

Comment 3

[Iain Ireland [:iain]]

The shell flag is --disable-bailout-loop-check. I'm not sure that there's an easy way to set it in the browser, but if you're looking for the easiest fix in your local build, changing false to true here should do the trick.

In the meantime, I'll try to figure out the underlying problem.

Comment 4

[Matthew Gaudet (he/him) [:mgaudet]]

oops; I totally meant pref vs. flag!

Comment 5

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

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

The shell flag is --disable-bailout-loop-check. I'm not sure that there's an easy way to set it in the browser, but if you're looking for the easiest fix in your local build, changing false to true here should do the trick.

In the meantime, I'll try to figure out the underlying problem.

Thanks! Appreciate the work around.

Comment 6

[Iain Ireland [:iain]]

Attachment: Bug 1698609: Use shape from template object when cloning RegExp r=tcampbell

If we parse offthread, then the shape of the template object will be allocated in a separate zone with a different initialShapes set. CodeGenerator::visitRegExp will create a new regexp using the shape of the template object. To remain consistent and avoid failed shape guards / bailout loops, we should do the same in CloneRegExpObject.

I played around with offThreadCompileScript and friends for a while trying to replicate the problem in the shell, but I couldn't get a testcase to work. This fixes the browser issue, though.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/70bc9f02feee
Use shape from template object when cloning RegExp r=tcampbell

Comment 8

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/70bc9f02feee

Comment 10

[Intermittent Failures Robot]

1 failures in 3445 pushes (0.0 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• autoland: 1

Platform and build breakdown:

• linux1804-64-qr: 1
  • debug: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=1698609&startday=2022-01-24&endday=2022-01-30&tree=all