Open Bug 1821411 Opened 2 years ago Updated 6 months ago

Crash in [@ RtlQueryPerformanceCounter | mozilla::glue::ModuleLoadFrame::StaticInit]

Categories

(Toolkit :: Application Update, defect)

Unspecified
Windows 10
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.

Hey David, it seems the error occurs in toolkit/xre/dllservices - any chance you could take a look or delegate?

Flags: needinfo?(davidp99)

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.)

Component: General → Installer
Flags: needinfo?(davidp99)
Product: Core → Firefox
Severity: -- → S3
Component: Installer → Application Update
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.