Assertion failure: cx->isExceptionPending(), at js/src/jit/Bailouts.cpp:319
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox133 | --- | fixed |
People
(Reporter: sm-bugs, Assigned: jandem)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
Steps to reproduce:
Checkout commit 6b6c3965d0a79880493b8ae44a92389b72d90636 and invoke the js shell as follows:
js --fast-warmup --fuzzing-safe <testcase>
Actual results:
Assertion failure: cx->isExceptionPending(), at js/src/jit/Bailouts.cpp:319
==2768723==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000000 (pc 0x5627b073cdf1 bp 0x7fff0de6b740 sp 0x7fff0de6b610 T2768723)
==2768723==The signal is caused by a WRITE memory access.
==2768723==Hint: address points to the zero page.
#0 0x5627b073cdf1 in js::jit::ExceptionHandlerBailout(JSContext*, js::jit::InlineFrameIterator const&, js::jit::ResumeFromException*, js::jit::ExceptionBailoutInfo const&) js/src/jit/Bailouts.cpp:319:5
#1 0x5627b0e50e1e in js::jit::HandleExceptionIon(JSContext*, js::jit::InlineFrameIterator const&, js::jit::ResumeFromException*, bool*) js/src/jit/JitFrames.cpp:314:15
#2 0x5627b0e50e1e in js::jit::HandleException(js::jit::ResumeFromException*) js/src/jit/JitFrames.cpp:787:9
#3 0x307b2eabc5e5 (<unknown module>)
I would be grateful if there were a grace period to fix up posts.
Updated•5 months ago
|
Assignee | ||
Updated•5 months ago
|
Comment 4•5 months ago
|
||
(In reply to Nils Bars from comment #2)
I would be grateful if there were a grace period to fix up posts.
I think if you have editbugs you can do it yourself. See instructions here
Comment 5•5 months ago
|
||
(In reply to Matthew Gaudet (he/him) [:mgaudet] from comment #4)
I think if you have editbugs you can do it yourself. See instructions here
Most people don't have editbugs, unless they are employees.
Comment 6•5 months ago
|
||
(In reply to Andrew McCreight [:mccr8] from comment #5)
Most people don't have editbugs, unless they are employees.
True, but it's wide open to get it with a very low bar
Assignee | ||
Comment 7•5 months ago
|
||
This is a small but nasty test case :) What happens is:
- We throw an overrecursion exception and this triggers an "exception handler bailout" from Ion to resume at a catch-block in the Baseline Interpreter.
- During the bailout, we execute a
RegExpMatcher
recover instruction that executes a regular expression. - The test calls
timeout
, and this timeout is handled during this regular expression execution. This clears the pending exception and we now throw an uncatchable exception to stop execution. - The exception bailout code doesn't expect this change from catchable to uncatchable exception.
This looks like an overzealous assertion. There's another one in HandleExceptionIon
and if I remove both of them, I think we do the right thing and the test finishes executing.
I don't really like deleting these assertions for this edge case though. I'll see if we can track these uncatchable exceptions a bit better.
Let's keep this hidden for now but I don't think this is security-sensitive.
Assignee | ||
Comment 8•5 months ago
|
||
Bailouts can execute recover instructions, and recover instructions can perform
an interrupt check that can throw an uncatchable exception.
We don't have a good way to check if we're currently throwing an uncatchable exception,
so this patch adds a flag to the context that's true if we've ever thrown one.
This way we can still catch bugs caused by incorrectly returning false
or nullptr
without throwing an exception.
Updated•5 months ago
|
Assignee | ||
Updated•5 months ago
|
(In reply to Matthew Gaudet (he/him) [:mgaudet] from comment #6)
(In reply to Andrew McCreight [:mccr8] from comment #5)
Most people don't have editbugs, unless they are employees.
True, but it's wide open to get it with a very low bar
Thanks!
Comment 10•5 months ago
|
||
Comment 11•5 months ago
|
||
bugherder |
Description
•