1704684 - Improve stability and performance of SharedLibraryInfo::GetInfoForSelf

Status: RESOLVED DUPLICATE of bug 1702086

(Core :: Gecko Profiler, defect, P2)

Description

[Toshihito Kikuchi [:toshi]]

Bug 1702086 reduced the number of crashes in SharedLibraryInfo::GetInfoForSelf, but the crash still happens because there is a slim timing window where the module could be unloaded.

Comment 1

[Toshihito Kikuchi [:toshi]]

Attachment: Bug 1704684 - Part 1: Make sure LoadLibraryEx locks the module by checking HMODULE. r=mstange

Bug 1702086 had LoadLibraryEx run before GetModuleInformation so that if the module
was already unloaded, we could detect it by checking the return value from GetModuleInformation.

With that patch, however, the same crash still happens and the minidumps indicate LoadLibraryEx
loaded a module onto an address different from hMods[i]. One possible situation which can cause
it is the module was unloaded between GetModuleFileNameEx and LoadLibraryEx, and it was loaded
again between LoadLibraryEx and GetModuleInformation.

This patch detects the situation where the module was unloaded by checking HMODULE returned from
LoadLibraryEx. If LoadLibraryEx returned the same value as hMods[i], it's clear that we
successfully incremented the module's refcount i.e. locked the loaded module.

Comment 2

[Toshihito Kikuchi [:toshi]]

Attachment: Bug 1704684 - Part 2: Use nt::PEHeaders instead of GetModuleInformation. r=mstange

Because SharedLibraryInfo::GetInfoForSelf() only needs the start/end address of
a module's mapped region in the local process, we can use nt::PEHeaders instead of
GetModuleInformation. It's roughly 100x faster because GetModuleInformation uses
two system calls NtQueryInformationProcess and NtReadVirtualMemory
while nt::PEHeaders does not.

Depends on D111767

Comment 3

[Toshihito Kikuchi [:toshi]]

Bug 1702086 was reopened due to a regression. Resolving this as a dup.