1743265 - Crash in [@ RtlpFreeHeapInternal | RtlFreeHeap | nsCOMPtr_base::assign_from_qi | IPC::ParamTraits<nsIReferrerInfo*>::Read]

Status: RESOLVED WORKSFORME

(External Software Affecting Firefox :: Other, defect)

Description

[Andrew McCreight [:mccr8]]

Crash report: https://crash-stats.mozilla.org/report/index/ce94af06-e1af-4a55-ae8d-b4c4f0211127

Reason: STATUS_HEAP_CORRUPTION

Top 10 frames of crashing thread:

0 ntdll.dll RtlReportFatalFailure 
1 ntdll.dll RtlReportCriticalFailure 
2 ntdll.dll RtlpHeapHandleError 
3 ntdll.dll RtlpHpHeapHandleError 
4 ntdll.dll RtlpLogHeapFailure 
5 ntdll.dll RtlpFreeHeapInternal 
6 ntdll.dll RtlFreeHeap 
7  @0xb7434f 
8 xul.dll nsCOMPtr_base::assign_from_qi xpcom/base/nsCOMPtr.cpp:50
9 xul.dll static IPC::ParamTraits<nsIReferrerInfo*>::Read dom/ipc/ReferrerInfoUtils.cpp:53

There's a bunch of crashes like this. I see a few different but similar signatures. The crashes are almost entirely locale zh-CN.

Comment 1

[Andrew McCreight [:mccr8]]

[Tracking Requested - why for this release]: frequent new crash in 94

Comment 2

[Andrew McCreight [:mccr8]]

The ones I looked at were all in BrowserParent::RecvOnLocationChange().

Comment 3

[Andrew McCreight [:mccr8]]

[@ RtlpFreeHeapInternal | RtlFreeHeap | nsTSubstring<T>::SetLength ] which was in the signature spikes report looks to be another variant of this.

Comment 4

[Gabriele Svelto [:gsvelto]]

The stacks are fairly messed up but this seems to be happening when receiving an OnLocationChange message over IPC (here). Something seems to be going wrong when de-serializing the message.

Comment 5

[Andrew McCreight [:mccr8]]

For one signature I looked at, about 28% of the crashes had Fission enabled, so I'd guess it is unrelated to Fission specifically.

Comment 6

[Andrew McCreight [:mccr8]]

dveditz noticed that the crashes started on the 18th, which is while after 94.0.1 was released. Looking at one crash report, I noticed that the extension [e-mail] has version 5.95.0buildid20211118.065505, which would seem to contain November 18, so that's maybe related. We still probably shouldn't crash in this code no matter what an extension is doing so it would be nice to figure out what is going wrong.

Comment 7

[Hector Zhao [:hectorz]]

(In reply to Andrew McCreight [:mccr8] from comment #6)

... Looking at one crash report, I noticed that the extension [e-mail] has version 5.95.0buildid20211118.065505, which would seem to contain November 18, so that's maybe related. ...

This version of the extension was built on Nov. 18th but not signed and released until Nov. 23rd.

We do listen for onLocationChange in our extensions, but neither has anything related to nsIReferrerInfo in them.

Comment 8

[Andrew McCreight [:mccr8]]

I looked at the reports again, and there's a very high correlation with something called SafeWrapper.dll, which is apparently something by Qihoo 360, so maybe this is a case of some antivirus software trying to affect Firefox and causing an issue.

I also noticed that the fact that RtlFreeHeap, which is related to the Windows allocator, is in the stack doesn't make much sense, because FireFox uses its own allocator jemalloc. Maybe something tried to replace our free function, and we end up passing a pointer from jemalloc into the Windows allocator, and then it notices that the pointer is weird and so it crashes?

Anyways, I'm going to move this to the component for antivirus-y issues.

Comment 9

[Gabriele Svelto [:gsvelto]]

We already had problem with that particular piece of software, see bug 1706031.

Comment 10

[Ryan VanderMeulen (PTO, back 6-April)]

No time to address this in 94, but let's keep this on the radar for 95/96.

Comment 11

[Pascal Chevrel:pascalc]

Crashes stopped with 95

Comment 12

[Dianna Smith [:diannaS]]

:mccr8 Since the crashes stopped in 95, is there anything left to do with this ticket?

Comment 13

[Andrew McCreight [:mccr8]]

Not as far as I can tell.