Collect reason for failing to LoadLibraryW on Utility process
Categories
(Core :: IPC, enhancement)
Tracking
()
People
(Reporter: gerard-majax, Assigned: gerard-majax)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
48 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
|
Details | Review |
2.48 KB,
text/plain
|
chutten|PTO
:
data-review+
|
Details |
We have very few actionable reports on crash-stats for [@ mozilla::ipc::UtilityAudioDecoderParent::GenericPreloadForSandbox ]
(second top entry) while figures on https://www.mathies.com/mozilla/crashes/utilrelease.html shows this is hitting more than a few clients, so collecting exact error reason will help us.
Assignee | ||
Comment 1•2 years ago
|
||
Assignee | ||
Comment 2•2 years ago
|
||
Data review request as suggested for MOZ_CRASH_UNSAFE_PRINTF()
in https://searchfox.org/mozilla-central/rev/2ce39261ea6a69e49d87f76a119494b2a7a7e42a/mfbt/Assertions.h#271-282
Comment 3•2 years ago
|
||
Comment on attachment 9327909 [details]
data review
DATA COLLECTION REVIEW RESPONSE:
Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?
Yes.
Is there a control mechanism that allows the user to turn the data collection on and off?
Yes. This collection can be controlled through Firefox's Preferences.
If the request is for permanent data collection, is there someone who will monitor the data over time?
Yes, Alexandre Lissy is responsible.
Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?
Category 1, Technical.
Is the data collection request for default-on or default-off?
Default on for all channels.
Does the instrumentation include the addition of any new identifiers?
No.
Is the data collection covered by the existing Firefox privacy notice?
Yes.
Does the data collection use a third-party collection tool?
No.
Result: datareview+
Comment 5•2 years ago
|
||
bugherder |
Assignee | ||
Comment 6•2 years ago
|
||
Comment on attachment 9327907 [details]
Bug 1827380 - Collect GetLastError in MOZ_CRASH for Utility preload failure r?#ipc-reviewers!
Beta/Release Uplift Approval Request
- User impact if declined: None
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): We just add debug info in the
MOZ_CRASH
statement - String changes made/needed: N/A
- Is Android affected?: No
Comment 7•2 years ago
|
||
Comment on attachment 9327907 [details]
Bug 1827380 - Collect GetLastError in MOZ_CRASH for Utility preload failure r?#ipc-reviewers!
Approved for 113.0b9. Fingers crossed it helps!
Comment 8•2 years ago
|
||
bugherder uplift |
Assignee | ||
Comment 9•2 years ago
•
|
||
Telemetry is starting to get data:
Unable to preload module: 0x3e6 => ERROR_NOACCESS "Invalid access to memory location."
Unable to preload module: 0x5af => ERROR_COMMITMENT_LIMIT "The paging file is too small for this operation to complete."
Unable to preload module: 0x45a => ERROR_DLL_INIT_FAILED => "A DLL initialization routine failed."
Unable to preload module: 0x7e => ERROR_MOD_NOT_FOUND => "The specified module could not be found."
Assignee | ||
Comment 10•2 years ago
|
||
And for volumetry:
340 Unable to preload module: 0x7e
20 Unable to preload module: 0x45a
20 Unable to preload module: 0x5af
12 Unable to preload module: 0x3e6
Comment 11•2 years ago
|
||
I looked into this yesterday but forgot to leave a comment. In Socorro the vast majority of the crashes that have ERROR_MOD_NOT_FOUND
as the crash reason are also OOMs, most of them on 32-bit hosts caused by excessive virtual address space fragmentation. Chances are you're seeing the same thing here, the process can't load a DLL but the real reason is that it can't find a chunk of address space large enough to map it.
Description
•