1713160 - Crash in [@ LdrpICallHandler]

Status: RESOLVED FIXED

(Toolkit :: Crash Reporting, defect)

Description

[alex_mayorga]

Crash report: https://crash-stats.mozilla.org/report/index/83a17c09-2008-41d2-ba5e-d836d0210525

Reason: STATUS_STACK_BUFFER_OVERRUN / FAST_FAIL_GUARD_ICALL_CHECK_FAILURE

Top 3 frames of crashing thread:

0 ntdll.dll LdrpICallHandler 
1 ntdll.dll RtlpExecuteHandlerForException 
2 ntdll.dll RtlDispatchException 

More reports at https://crash-stats.mozilla.org/signature/?product=Firefox&signature=LdrpICallHandler

Comment 1

[Gabriele Svelto [:gsvelto]]

All the crashes here are different. We should add RtlDispatchException to Socorro's prefix or ignore lists to tell them apart. Also all these crashes are __fastfail() crashes intercepted by WER.

Comment 2

[Richard Leger]

FYI, this bug occured to me in TB 90.0b3 (64-bit) just now... while setting an IMAP msg as read via mouse click on the bullet icon in email msg list...
bp-12c71778-1dd5-4e08-afa1-bf9790210705

Comment 3

[Adrian Florinescu [:aflorinescu]]

Gabrielle, is there anything actionable for this crash? Or too generic and unactionable until bug 1715747 gets underway?

Comment 4

[Wayne Mery (:wsmwk)]

10x increase in Firefox crashes starting early June https://crash-stats.mozilla.org/signature/?signature=LdrpICallHandler&date=%3E%3D2021-04-27T14%3A37%3A00.000Z&date=%3C2021-07-27T14%3A37%3A00.000Z#graphs

(In reply to Richard Leger from comment #2)

FYI, this bug occured to me in TB 90.0b3 (64-bit) just now... while setting an IMAP msg as read via mouse click on the bullet icon in email msg list...
bp-12c71778-1dd5-4e08-afa1-bf9790210705

I'm pretty sure your crash is imap, and will not be related to this bug report.

Comment 5

[Gabriele Svelto [:gsvelto]]

Bug 1715747 changed this but the resulting signatures aren't particularly interesting either, see @LdrpHandleInvalidUserCallTarget. Additionally I noticed that a bunch of crashes we have here aren't using CFI when generating the stack because the affected DLL wasn't processed correctly. I'm fixing that and I'll file a follow up to bug 1715747 then let's see what happens.

The volume increase that happened before the signature change was most likely due to WER now catching content process crashes too.

Comment 6

[Simona Badau, Desktop QA]

Hi, can someone from our dev team help us find a component for this issue? I tried to find the right place to put it but nothing comes to mind based on the info from this report.
Thanks!

Comment 7

[Gabriele Svelto [:gsvelto]]

After bug 1715747 there's not much left to do here. The remaining stack traces are extremely narrow and there's not much we can tell about what's going on. Move it to Toolkit > Crash Reporting and I'll have another look some time from now to see if the volume has abated or if it's still an issue.

Comment 8

[alex_mayorga]

¡Hola Gabriele!

Hope these lines find you well.

What does CFI and WER mean on your comments above, por favor?

Should this bug be resolved now?

¡Gracias!
Alex

Comment 9

[Gabriele Svelto [:gsvelto]]

(In reply to alex_mayorga from comment #8)

What does CFI and WER mean on your comments above, por favor?

CFI: Call frame information. It's a set of rules used to unwind the stack given an instruction pointer

WER: Windows Error Reporting. You can read the comments in bug 1682507 for some background on that. In a nutshell it's a Windows service that enables us to catch crashes that cannot be caught from withing the application.

Should this bug be resolved now?

No, I prefer keeping it open to investigate what's happening with the remaining volume.

Comment 10

[Gabriele Svelto [:gsvelto]]

I had another quick look but nothing really stands out.

Comment 11

[Gabriele Svelto [:gsvelto]]

After a bit more fiddling I found something interesting: half of the crashes here start with a STATUS_HEAP_CORRUPTION exception. We then hit another issue within the exception handler itself, the exception machinery seems to assume the stack is messed up at this point and then throws STATUS_STACK_BUFFER_OVERRUN / FAST_FAIL_GUARD_ICALL_CHECK_FAILURE which is ultimately called by WER. This must also be the reason why the stack unwinding fails so early. One possibility here would be not to handle STATUS_HEAP_CORRUPTION crashes anymore in Breakpad but leave them to WER entirely.

Comment 12

[Gabriele Svelto [:gsvelto]]

Attachment: Bug 1713160 - Avoid crashes when setting the description of the minidump generation thread r=rkraesig

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/30163ad3602d
Avoid crashes when setting the description of the minidump generation thread r=rkraesig

Comment 14

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/30163ad3602d

Comment 15

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for ESR102 approval when you get a chance.

Comment 16

[Gabriele Svelto [:gsvelto]]

Comment on attachment 9282188 [details]
Bug 1713160 - Avoid crashes when setting the description of the minidump generation thread r=rkraesig

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Fixes a crash that affects users with certain types of anti-virus software installed
• User impact if declined: Firefox crashes (probably on startup)
• Fix Landed on Version: 103
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The change doesn't affect how the code works, it just checks if a function returns a NULL pointer and avoids crashing if it does

Comment 17

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9282188 [details]
Bug 1713160 - Avoid crashes when setting the description of the minidump generation thread r=rkraesig

Approved for 102.1esr.

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr102/rev/ab7b0f24d2d2