1956290 - Nightly unable to send crash report for this particular crash

Status: RESOLVED MOVED

(Toolkit :: Crash Reporting, defect)

Description

[Mayank Bansal]

I will share the .dmp file on email or via DM.
This crash occurred on 18Mar2025 and Nightly still hasnt been able to create a crash report.

Comment 1

[Mayank Bansal]

Attachment: about:support

Comment 2

[Gian-Carlo Pascutto [:gcp]]

Going to mark S2 for now similarly to bug https://bugzilla.mozilla.org/show_bug.cgi?id=1322097

Comment 3

[:gerard-majax]

Nothing shows in the JS console? Not the devtools, the browser console

Comment 4

[Mayank Bansal]

(In reply to :gerard-majax from comment #3)

Nothing shows in the JS console? Not the devtools, the browser console

failed: missing extra file crashes.js:163:17
submitPendingReport chrome://global/content/crashes.js:163

Comment 5

[:gerard-majax]

(In reply to Mayank Bansal from comment #4)

(In reply to :gerard-majax from comment #3)

Nothing shows in the JS console? Not the devtools, the browser console

failed: missing extra file crashes.js:163:17
submitPendingReport chrome://global/content/crashes.js:163

Can you check if it's truly missing ?

Comment 6

[Mayank Bansal]

There is only the .dmp file in the folder. There wasnt any .extra file if thats what you meant to ask.

Comment 7

[:gerard-majax]

Seems like it's on purpose: https://searchfox.org/mozilla-central/rev/ac605820636c3b964542a2c0589af04a02235d00/toolkit/crashreporter/CrashSubmit.sys.mjs#333

Comment 8

[Gabriele Svelto [:gsvelto]]

I've analyzed the minidump and this is the symptom of a larger problem we have with crash generation: the root of the issue is that we've encountered a heap corruption exception in Microsoft's code. This type of exception is thrown by Windows' default memory allocator and thus we only encounter it outside of our code (which uses jemalloc). Breakpad's vanilla exception handler didn't support catching heap corruption exceptions so I've added support for them in bug 1633052. There's one caveat with that patch: we use several Windows functions to handle writing out a minidump and if the heap is indeed corrupted we might trigger another similar exception. When that happens we give up everything and terminate Firefox, so if the crash report was not fully written out - as is the case here - we leave it half-formed and Firefox is unable to submit it.

I will file a separate bug to address the root issue but it will need support for out-of-process crash reporting. Specifically we probably want to do as little as possible in the exception handler so that we don't trigger a recursive exception, and unload all the crash generation to the out-of-process generator. Alternatively we might remove the exception handler entirely, let it bubble up and be caught by WER. This would be even best because the least we do in the exception handler the better it is. However I've not verified if WER catches it and besides we still need to make WER work with sandboxed child processes.

Comment 9

[Gabriele Svelto [:gsvelto]]

Closing this as MOVED since I fixed part of it in bug 1620998, the remaining underlying problem is described in bug 1966720.