Crash in [@ RtlQueryPerformanceCounter | mozilla::glue::ModuleLoadFrame::StaticInit]
Categories
(Toolkit :: Application Update, defect)
Tracking
()
People
(Reporter: gsvelto, Unassigned)
Details
(Keywords: crash)
Crash Data
Crash report: https://crash-stats.mozilla.org/report/index/d1fc72a3-741f-47dd-a411-1941e0230309
Reason: EXCEPTION_ACCESS_VIOLATION_WRITE
Top 9 frames of crashing thread:
0 ntdll.dll RtlQueryPerformanceCounter
1 mozglue.dll mozilla::glue::ModuleLoadFrame::StaticInit toolkit/xre/dllservices/mozglue/ModuleLoadFrame.cpp:57
2 mozglue.dll DllBlocklist_Initialize toolkit/xre/dllservices/mozglue/WindowsDllBlocklist.cpp:610
3 firefox.exe NS_internal_main browser/app/nsBrowserApp.cpp:376
3 firefox.exe wmain toolkit/xre/nsWindowsWMain.cpp:127
4 firefox.exe invoke_main /builds/worker/workspace/obj-build/browser/app/d:/agent/_work/2/s/src/vctools/crt/vcstartup/src/startup/exe_common.inl:90
4 firefox.exe __scrt_common_main_seh /builds/worker/workspace/obj-build/browser/app/d:/agent/_work/2/s/src/vctools/crt/vcstartup/src/startup/exe_common.inl:288
5 kernel32.dll BaseThreadInitThunk
6 ntdll.dll RtlUserThreadStart
I'm not sure where to file this because it's not a crash we can fix directly but maybe it could be a symptom of a failure either in the installer or in the updater process. Long story short: all the crashes under this signature have a mix of libraries from different versions of Firefox. This bug for example has the following at the end of the modules list:
firefox.exe 109.0.1.8427 21B8E288E931E2704C4C44205044422E1 firefox.pdb Mozilla Corporation
mozglue.dll 110.0.0.8445 6FA603161165766D4C4C44205044422E1 mozglue.pdb Mozilla Corporation
Here's another example:
firefox1.exe 105.0.1.8300 0827CAB1D331B2194C4C44205044422E1 firefox.pdb Mozilla Corporation
mozglue.dll 110.0.1.8458 3402E350F3EE6AC54C4C44205044422E1 mozglue.pdb Mozilla Corporation
Note how the name of the Firefox executable is not firefox.exe.
Another data point is that version 109.0.1 seems to be disproportionately affected by this compared to other versions.
Comment 1•2 years ago
|
||
Hey David, it seems the error occurs in toolkit/xre/dllservices - any chance you could take a look or delegate?
Comment 2•2 years ago
|
||
Comment 0 called it right, including the part about v109.0.1 being the worst hit -- but that's because it was the last release before version 110.0.
The crash is failing to get the SharedSection object because that function is new in version 110 (see bug 1744362). So, when your firefox.exe is a version before that, this code has ModuleLoadFrame::StaticInit (which is in mozglue.dll) calling LoaderAPI::GetSharedSection in (an older version of) firefox.exe via a vtable... but the vtable was created by the older firefox.exe and therefore doesn't contain a pointer to the new LoaderAPI::GetSharedSection subclass-method-implementation -- we're reading garbage for the function pointer, and then crashing when we use it.
This explains why the crashes spike dramatically for builds mixing pre-v110 and post-v110 firefox.exe and mozglue.dlls. It also shows that we can expect this particular crash not to return. But future code changes can create similar issues. Since we would expect the browser to crash soon after this anyway (due to the mixed versions) we may not want to do anything about it. But this info might be useful to people working on the updater, so I'm passing it on to them.
(I'm setting the component to "Installer" because "Application Update" only seems to exist in the docs. Please redirect it is this is wrong.)
Updated•2 years ago
|
Description
•