Closed Bug 1431042 Opened 6 years ago Closed 4 months ago

Crash in OOM | unknown | js::AutoEnterOOMUnsafeRegion::crash | js::jit::TryAttachCallStub

Categories

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

Unspecified
Windows 10
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: cyu, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: crash, Whiteboard: qa-not-actionable)

Crash Data

Attachments

(1 file)

This bug was filed from the Socorro interface and is
report bp-9cb20994-b1f6-406a-a45d-01a830180117.
=============================================================

Top 4 frames of crashing thread:

0 xul.dll js::AutoEnterOOMUnsafeRegion::crash js/src/jscntxt.cpp:1651
1 xul.dll js::jit::TryAttachCallStub js/src/jit/BaselineIC.cpp:2255
2 xul.dll js::jit::DoCallFallback js/src/jit/BaselineIC.cpp:2528
3  @0x1ccb1bc7611 

=============================================================
18 crashes in 13 installations in the past 6 days on 52esr, 57, 58 and 59. Not really a top crash but I still file the bug because the OOM is interesting. The crash reason is "[unhandlable oom] Could not allocate ObjectGroup in EnsureTrackPropertyTypes". It crashes on 64 bit when there is still physical memory. For this crash https://crash-stats.mozilla.com/report/index/cb7fd581-0d3e-4f9c-ae7e-3d3c60180112 , it even OOM crashes when there is 23 GiB of physical memory.
Nicolas, could you take a deeper look? Thanks.
Flags: needinfo?(nicolas.b.pierron)
Priority: -- → P3
I'm getting some crashes with this signature, but I think it's actually bug 1498348
This bug correspond to 2 different code ath, one which is in Baseline IC and should probably be investigated by Matthew, and the other is a small allocation OOM on the creation of group object.

Both are low volume and sounds safe to be a low priority at the moment.
Flags: needinfo?(nicolas.b.pierron)

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

This bug correspond to 2 different code ath, one which is in Baseline IC and
should probably be investigated by Matthew, and the other is a small
allocation OOM on the creation of group object.

Both are low volume and sounds safe to be a low priority at the moment.

We had a handful of crashes per day at the beginning of the year, but it has been steadily going up over the summer and we are now around 70 crashes per day. Has something changed over the summer that would explain that? Should that remain a p3? Thanks

Flags: needinfo?(nicolas.b.pierron)

Yes, since we enabled the Baseline-Interpreter which is relying on CacheIR mechanism.
Forwarding the needinfo to Jan.

Flags: needinfo?(nicolas.b.pierron) → needinfo?(jdemooij)

This probably can be resummaried: TryAttachCallStub is gone, and the sig that is rising is only EnsureTrackPropertyTypes.

(In reply to Matthew Gaudet (he/him) [:mgaudet] from comment #7)

This probably can be resummaried: TryAttachCallStub is gone, and the sig that is rising is only EnsureTrackPropertyTypes.

Yes this is crashing on OOM in EnsureTrackPropertyTypes and we call that in a number of different places... It could also be that we reached the max GC heap size (4 GB still I think?).

Flags: needinfo?(jdemooij)
Whiteboard: qa-not-actionable
Severity: critical → S2

Since the crash volume is low (less than 5 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit auto_nag documentation.

Severity: S2 → S3

Closing because no crashes reported for 12 weeks.

Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: