Crash in OOM | unknown | mozalloc_abort | mozalloc_handle_oom | moz_xmalloc | mozilla::BufferList<T>::AllocateSegment in GPU process

NEW
Unassigned

Status

()

defect
P3
critical
2 years ago
2 years ago

People

(Reporter: mccr8, Unassigned)

Tracking

({crash})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [gfx-noted], crash signature)

Reporter

Description

2 years ago
This bug was filed from the Socorro interface and is 
report bp-f55fa65b-5c11-4257-ae33-491122170323.
=============================================================

#6 Windows crash for the 3-23 Nightly, though only from a few installation. There doesn't seem to be any information in the crash report about memory usage, presumably because that hasn't been hooked up yet for the GPU process.
Reporter

Comment 1

2 years ago
David, this might be interesting for you to look at.
Flags: needinfo?(dvander)

Comment 2

2 years ago
bug 1349991 probably related
Adding a similar signature found in nightly review.
Crash Signature: [@ OOM | unknown | mozalloc_abort | mozalloc_handle_oom | moz_xmalloc | mozilla::BufferList<T>::AllocateSegment] → [@ OOM | unknown | mozalloc_abort | mozalloc_handle_oom | moz_xmalloc | mozilla::BufferList<T>::AllocateSegment] [@ moz_abort | arena_run_split | arena_malloc_large | moz_xmalloc | mozilla::BufferList<T>::AllocateSegment]
Reporter

Updated

2 years ago
See Also: → 1352471
(In reply to Andrew McCreight [:mccr8] from comment #0)
> This bug was filed from the Socorro interface and is 
> report bp-f55fa65b-5c11-4257-ae33-491122170323.
> =============================================================
> 
> #6 Windows crash for the 3-23 Nightly, though only from a few installation.
> There doesn't seem to be any information in the crash report about memory
> usage, presumably because that hasn't been hooked up yet for the GPU process.

Do these crashes also appear in the UI process? (Or maybe it's easier to OOM somewhere else there first?) Also, how can we get that memory usage info hooked up?
Flags: needinfo?(dvander) → needinfo?(continuation)
Reporter

Comment 5

2 years ago
(In reply to David Anderson [:dvander] from comment #4)
> Do these crashes also appear in the UI process?

If you click on the crash signature links, in the upper right there's a breakdown by process type.

The signature  OOM | unknown | mozalloc_abort | mozalloc_handle_oom | moz_xmalloc | mozilla::BufferList<T>::AllocateSegment is in a plugin process 88% of the time, and GPU process 4.3% of the time. The other signature is in the GPU process 18% of the time. (If no process type is given, it is the main process). So over all, these aren't particularly specific to the GPU process.

Maybe one process is trying to send a lot of messages, but the other process can't keep up and so the sender gets too many messages and crashes. We've seen similar odd crashes before, where the message queue failed to allocate when growing, when it was already a few megs. Which is a lot of messages.

> Also, how can we get that memory usage info hooked up?

There's some crash reporter ish stuff that has to be written. I'm not familiar with the specifics. Bug 1236108 and bug 1257486 added some of these annotations to the content process, so presumably something similar would need to happen for the GPU process. Bug 1263774 covered storing memory reports for the content process, though that's harder to do and hasn't been quite as useful in the past for memory issues, IMO.
Flags: needinfo?(continuation)

Comment 6

2 years ago
> Maybe one process is trying to send a lot of messages, but the other process can't keep up and so the sender gets too many messages and crashes. We've seen similar odd crashes before, where the message queue failed to allocate when growing, when it was already a few megs. Which is a lot of messages.

That is pretty much what I suspect is happening in bug 1349991. In that case messages actually keep piling up in multiple processes until one or more experience an OOM. In my case it usually hits the gfx process first and then maybe a content process.
Reporter

Comment 7

2 years ago
Ah, yes, now I see that the signatures for your crashes match that. I'll mark this as depending on that because you have some actual steps to reproduce.
Depends on: 1349991
Priority: -- → P3
Whiteboard: [gfx-noted]

Comment 8

2 years ago
I just had the same crash: https://crash-stats.mozilla.com/report/index/f6aa9bfb-3bca-481c-ac6c-a987c0170918, and there are no steps to reproduce.

I was doing nothing with the browser at the moment when it decided to blow up on me until it OOMed and crashed one of the FF processes.

You guys discussed messages. But in my case it looks like FF has accumulated 35 GB of it before reaching OOM. Is this even possible?
Reporter

Updated

2 years ago
See Also: → 1400000
You need to log in before you can comment on or make changes to this bug.