1657634 - Crash in [@ OOM | unknown | js::AutoEnterOOMUnsafeRegion::crash | js::irregexp::Execute]

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect, P3)

Description

[Sean Feng [:sefeng211]]

This bug is for crash report bp-876fd1b0-8165-440f-95a5-5d59e0200731.

Top 10 frames of crashing thread:

0 xul.dll js::AutoEnterOOMUnsafeRegion::crash js/src/vm/JSContext.cpp:1194
1 xul.dll js::irregexp::Execute js/src/irregexp/RegExpAPI.cpp:608
2 xul.dll static js::RegExpShared::execute js/src/vm/RegExpObject.cpp:730
3 xul.dll ExecuteRegExp js/src/builtin/RegExp.cpp:1056
4 xul.dll js::RegExpTester js/src/builtin/RegExp.cpp:1232
5  @0x3604ef56 
6  @0x34c3af 
7 xul.dll static js::MovableCellHasher<JSObject*>::hash js/src/gc/Barrier.cpp:147
8 xul.dll trunc 
9  @0x34cb3b 

I figured this worth to file because we report the crash here explicitly. There are a decent number of crashes, starting at 79.

Comment 1

[Nicolas B. Pierron [:nbp]]

Based on the low number of crashes, I do not think this is worth fixing, as we might run out of memory one way or another. (unless these are large allocations?)

However, for the sake of asking, Iain, do you think we can safely remove the AutoEnterOOMUnsafeRegion::crash here?

Comment 2

[Iain Ireland [:iain]]

No, these OOMs are happening inside imported Irregexp code. It looks like they are all happening when we try reallocating the backtracking stack. We can't remove the AutoEnterOOMUnsafeRegion without upstreaming OOM-handling code to V8, which is a line I would prefer not to cross if we can avoid it.

Over 80% of these failures are on 32-bit x86, which makes sense, because the maximum size of the backtracking stack is the same for 32 and 64 bit. We could consider upstreaming a patch to decrease the maximum stack size on 32-bit, but I would only expect a marginal improvement in the crash rate.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.