Closed Bug 1702138 Opened 4 years ago Closed 3 years ago

startup crash in [@ xul.dll | GetProcessMitigationPolicy]

Categories

(Firefox :: Launcher Process, defect)

Unspecified
Windows 10
defect

Tracking

()

RESOLVED DUPLICATE of bug 1664308

People

(Reporter: aryx, Unassigned)

Details

(Keywords: crash)

Crash Data

Startup content crash, so far all crashes on Windows 10. Earliest affected version is Firefox 85 while version 89.0a1 observed 4 crashes last week.

There are 2 different (xul.dll unsymbolified) stacks. The one below and e.g. bp-263cd49a-a962-4fb4-9408-444220210330:

kernelbase.dll	GetProcessMitigationPolicy	
mozglue.dll	mozilla::IsWin32kLockedDown()	mozglue/misc/WindowsProcessMitigations.cpp:36 

Crash report: https://crash-stats.mozilla.org/report/index/eb064006-721a-4d2d-9b0e-c0e2f0210324

MOZ_CRASH Reason: MOZ_CRASH(OOM)

Top 10 frames of crashing thread:

0 xul.dll xul.dll@0xd60fec 
1 xul.dll xul.dll@0x76769 
2 xul.dll xul.dll@0x5daa5fe 
3 xul.dll xul.dll@0x75748 
4 xul.dll xul.dll@0x1ef83 
5 xul.dll xul.dll@0x5ed6772 
6 xul.dll xul.dll@0x5149f21 
7 xul.dll xul.dll@0xdae902 
8 xul.dll xul.dll@0x100b0 
9 xul.dll xul.dll@0x5d6fc62 

...

kernelbase.dll	GetProcessMitigationPolicy	
mozglue.dll	mozilla::detail::DynamicallyLinkedFunctionPtrBase<long (*)(void*, void*, void**, unsigned long long, unsigned long long, _LARGE_INTEGER*, unsigned long long*, SECTION_INHERIT, unsigned long, unsigned long)>::DynamicallyLinkedFunctionPtrBase(wchar_t const*, char const*)	mozglue/misc/DynamicallyLinkedFunctionPtr.h:58 

I checked the latest crashes:

For some reason, xul.dll is not symbolicated on crash-stats.mozilla.org, but the downloaded dumps were resolved with public symbols correctly. Both crashes happened NS_ABORT_OOM(0) here. So it's OOM and has nothing to do with GetProcessMitigationPolicy.

Gabriele, can you check why xul.dll is not symbolicated for this signature?

Flags: needinfo?(gsvelto)

xul.dll was unloaded in both crashes so there's no debug ID for it in the minidump, this typically happens during catastrophic OOM crashes. Our symbolication infrastructure relies on the debug ID so when it's missing we can't symbolicate a crash. I think Visual Studio can symbolicate those crashes by using the module's code ID alone but our machinery can't (yet).

Flags: needinfo?(gsvelto)

(In reply to Gabriele Svelto [:gsvelto] from comment #2)

xul.dll was unloaded in both crashes so there's no debug ID for it in the minidump, this typically happens during catastrophic OOM crashes. Our symbolication infrastructure relies on the debug ID so when it's missing we can't symbolicate a crash. I think Visual Studio can symbolicate those crashes by using the module's code ID alone but our machinery can't (yet).

Interesting. The Modules tab on crash-stats.mozilla.org does not show Debug ID, but in the minidumps xul.dll was loaded. Since this is a content process's crash, maybe the main process failed to retrieve Debug ID because the system was too catastrophic..?

The crashing stack is the same as bug 1664308. Resolving this as a dup.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE

(In reply to Toshihito Kikuchi [:toshi] from comment #3)

Interesting. The Modules tab on crash-stats.mozilla.org does not show Debug ID, but in the minidumps xul.dll was loaded. Since this is a content process's crash, maybe the main process failed to retrieve Debug ID because the system was too catastrophic..?

Yes, the module entry for xul.dll in those minidumps is populated but the debug ID is empty like for unloaded modules. It might be that the module hasn't actually been unloaded but maybe there isn't enough memory to retrieve the debug ID and store it in the minidump? Minidump generation was successful - otherwise we wouldn't have had a minidump at all - but that part is missing. W/o more information from Microsoft I don't know what that happens. Either way in the future we should be able to fix this in Socorro.

You need to log in before you can comment on or make changes to this bug.