startup crash in [@ xul.dll | GetProcessMitigationPolicy]
Categories
(Firefox :: Launcher Process, defect)
Tracking
()
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
Comment 1•3 years ago
|
||
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?
Comment 2•3 years ago
|
||
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).
Comment 3•3 years ago
|
||
(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.
Comment 4•3 years ago
|
||
(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.
Description
•