Closed Bug 1534840 Opened 6 months ago Closed 5 months ago

Assertion failure: !canNotPlacePool_, at js/src/jit/shared/IonAssemblerBufferWithConstantPools.h:971

Categories

(Core :: JavaScript Engine, defect, P2, critical)

ARM64
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla68
Tracking Status
firefox-esr60 --- unaffected
firefox66 --- disabled
firefox67 --- wontfix
firefox68 --- fixed

People

(Reporter: gkw, Assigned: nbp)

References

(Blocks 3 open bugs)

Details

(4 keywords, Whiteboard: [jsbugmon:])

Attachments

(6 files, 1 obsolete file)

The following testcase crashes on mozilla-central revision c89f024c023f (build with --enable-debug --disable-profiling --enable-more-deterministic --enable-simulator=arm64 and with Asan, run with --fuzzing-safe --wasm-compiler=none --wasm-gc --test-wasm-await-tier2 --ion-scalar-replacement=on --ion-edgecase-analysis=off --ion-eager --more-compartments --cpu-count=7 --gc-zeal=0,34 --no-incremental-gc --no-threads --baseline-eager):

See attachment.

See backtrace for Asan stack.

For detailed crash information, see attachment.

This is a hard-to-reproduce issue, but since there is an Asan stack, I hope this is useful. This should be related to IonMonkey on ARM64.

Attached file Testcase
Flags: needinfo?(sstangl)
Flags: needinfo?(nicolas.b.pierron)
Hardware: x86_64 → ARM64
Whiteboard: [jsbugmon:update] → [jsbugmon:]
Duplicate of this bug: 1529377

This is a JS fuzzing bug and sdetar said the team will fix as many as they can in 67 but will not be able to get to all. Marking them fix-optional.

Setting as P2 -- this type of crash is difficult to reproduce, but it occurs in TableSwitch and we ought to fix it by convincing ourselves of that code's safety.

Priority: -- → P2

So far I did not manage to reproduce the original issue, but I spawn it under rr and I will let it run for a few hours see if it catches anything.

I will try to proof read this code in the mean time.

Assignee: nobody → nicolas.b.pierron
Status: NEW → ASSIGNED
Flags: needinfo?(nicolas.b.pierron)

(In reply to Nicolas B. Pierron [:nbp] from comment #6)

[…] I spawn it under rr and I will let it run for a few hours see if it catches anything.

Letting it run over night is unsuccessful so far.

(In reply to Sean Stangl [:sstangl] from comment #5)

Setting as P2 -- this type of crash is difficult to reproduce, but it occurs in TableSwitch and we ought to fix it by convincing ourselves of that code's safety.

My biggest concern with this code is that fact that EmitData is being called for each pointer to be added as part of the jump table. I am tempted to clean-up this code to have a writeJumpTable function which would create a CodeLabelArray and call EmitData only once.

The previous patch is way too complicated, even if it would be nicer at the end but might have issues with very large jump-tables, there is zero chances to get it backported. I uploaded it for posterity.

I am investigating a simpler way … consisting of adding more assertions.

Attachment #9056110 - Attachment is obsolete: true
Pushed by npierron@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/639d0d388b96
part 0 - Clarify table case generation in CodeGenerator::visitOutOfLineSwitch. r=sstangl
https://hg.mozilla.org/integration/autoland/rev/4f54d68ba18e
part 1 - Add an assertion to check that we can generate contiguous jump tables. r=sstangl
https://hg.mozilla.org/integration/autoland/rev/e024cb135284
part 2 - Prevent ARM64 from generating constant pools within jump tables. r=sstangl
https://hg.mozilla.org/integration/autoland/rev/e55ace0633da
part 3 - Prevent ARM from generating nops within jump tables. r=sstangl
You need to log in before you can comment on or make changes to this bug.