Open Bug 1683284 Opened 9 months ago Updated 5 months ago

Crash in [@ OOM | large | mozalloc_abort | xul.dll | BaseThreadInitThunk] on Windows 7 x86 when viewing PDFs


(Core :: Graphics: WebRender, defect, P3)




Tracking Status
firefox-esr78 --- unaffected
firefox83 --- unaffected
firefox84 --- unaffected
firefox85 + wontfix
firefox86 + wontfix
firefox87 --- wontfix
firefox88 --- wontfix
firefox89 --- wontfix


(Reporter: aryx, Unassigned)


(Blocks 1 open bug)


(Keywords: crash, regression)

Crash Data

All of these frequent crashes are for x86 and almost all on Windows 7. They all seem to hit when the user views PDFs.

The same crash signature had been observed for 84.0b3 and no other 84 betas. Is it a regression from bug 1677818?

Crash report:


Top 10 frames of crashing thread:

0 mozglue.dll mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:33
1 mozglue.dll mozalloc_handle_oom memory/mozalloc/mozalloc_oom.cpp:51
2 xul.dll xul.dll@0x36a40aa 
3 xul.dll xul.dll@0x6df638 
4 xul.dll xul.dll@0x4349b4e 
5 xul.dll xul.dll@0x4342725 
6 xul.dll xul.dll@0x4341e76 
7 xul.dll xul.dll@0x38cfa67 
8 xul.dll xul.dll@0x143bc18 
9 xul.dll xul.dll@0x143b0a3 
Flags: needinfo?(matt.woodrow)

All the crash reports have lots of graphics critical errors, some about the shader cache and some about ShmemTextureHost failures.

Severity: -- → S3

Lots of those on 85 beta...

Jim can we get this looked into for 85?

Flags: needinfo?(jmathies)

I wonder if this bug is a signature change. None of the crashes seem to be properly symbolicated. We just get xul.dll.

Flags: needinfo?(gsvelto)

This is most likely a signature change. The minidump is missing xul.dll's debug ID so we can't symbolcate it properly, it tends to happen on Windows during catastrophic OOMs and these definitely are. For the rest the stacks are extremely similar to other OOMs where we don't have the xul.dll debug ID.

Flags: needinfo?(gsvelto)
Flags: needinfo?(matt.woodrow)
No longer blocks: gfx-triage, gfx-85
Flags: needinfo?(jmathies)

40-50% of the crashes with [@ xul.dll | _PR_NativeRunThread | pr_root] have a .pdf url and all for the last month are on Windows 7 x86. The signature started to spike on beta starting with Gecko 86 (signature change from [@ OOM | small] ?). Both signatures are tracked by bug 1519123.

Crash Signature: [@ OOM | large | mozalloc_abort | xul.dll | BaseThreadInitThunk] → [@ OOM | large | mozalloc_abort | xul.dll | BaseThreadInitThunk] [@ xul.dll | _PR_NativeRunThread | pr_root]

Jim, I am worried by the increase in volume in 86 beta vs 85 beta. Could we have somebody look at this crasher?
Also, it does not seem to be limited to windows 7 only, 69% of crashes for xul.dll | _PR_NativeRunThread | pr_root are on Windows 10. Thanks

Flags: needinfo?(jmathies)
OS: Windows 7 → Windows

Maybe this increase was caused by enabling software webrender on beta 86? Software webrender will not ride into release in 86 so perhaps we'll see a drop when early beta ends.

This bug is not very easy to make actionable as basically all we know is that it's an OOM large.

The volume looks like it did drop a little this week from 86.0b7 (late beta).

The level of crashes is similar on 86 late betas as they were on 85 betas so I think we are not in a worse shape as we were for 85.

Unsurprisingly this is spiking up again as sw-wr is enabled in early beta 87.

Blocks: gfx-triage
Flags: needinfo?(jmathies)
Blocks: sw-wr

Keeping this in triage for now, we're doing some work in 88 for x86.

Bug 1699224 may help if we can't find the virtual memory space (physical memory is low too).

Depends on: 1699224

Related - Bug 1695379 - WebRender ANGLE Crash in [@ OOM | large | mozalloc_abort | moz_xmalloc | std::vector<T>::_Emplace_reallocate<T>]

Bug 1699224 doesn't seem like something we can/should backport to Beta, so calling this wontfix for 88. Hopefully things improve in 89 :(

Waiting on 89 beta to see how much things have improved. We've landed changes there to help. Also, swiggle will not ship to 32-bit in 88.

No longer blocks: gfx-triage
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.