Open Bug 1508309 Opened 1 year ago Updated 1 year ago

Crash in IPC::ParamTraits<mozilla::net::nsHttpHeaderArray::nsEntry>::Write

Categories

(Core :: Networking: HTTP, defect, P3, critical)

Unspecified
Windows 10
defect

Tracking

()

Tracking Status
firefox63 --- wontfix
firefox64 --- wontfix
firefox65 --- fix-optional
firefox66 --- fix-optional

People

(Reporter: marcia, Unassigned)

Details

(Keywords: crash, regression, Whiteboard: [necko-triaged])

Crash Data

This bug was filed from the Socorro interface and is
report bp-41c8fb23-d926-48d9-85fb-b82b10181119.
=============================================================

Seen while looking at nightly crash stats - crashes started using  	20181118220115: https://bit.ly/2Tr7qNO. So far only 2 crashes.

Possible regression range based on Build ID: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=77223bb2fac278373dfcdde11fcda74b4c80aa61&tochange=7e9cac76980a2a4a10898c721c4a054db831ab4a

Top 10 frames of crashing thread:

0  @0x13d8245df28 
1 xul.dll IPC::ParamTraits<mozilla::net::nsHttpHeaderArray::nsEntry>::Write netwerk/protocol/http/PHttpChannelParams.h:133
2 xul.dll IPC::ParamTraits<nsTArray<mozilla::net::nsHttpHeaderArray::nsEntry> >::Write ipc/glue/IPCMessageUtils.h:609
3 xul.dll mozilla::net::PHttpChannelParent::SendOnStartRequest ipc/ipdl/PHttpChannelParent.cpp:80
4 xul.dll mozilla::net::HttpChannelParent::OnStartRequest netwerk/protocol/http/HttpChannelParent.cpp:1564
5 xul.dll nsresult mozilla::net::nsHttpChannel::CallOnStartRequest netwerk/protocol/http/nsHttpChannel.cpp:1774
6 xul.dll nsresult mozilla::net::nsHttpChannel::ContinueOnStartRequest2 netwerk/protocol/http/nsHttpChannel.cpp:7553
7 xul.dll nsresult mozilla::net::nsHttpChannel::ContinueOnStartRequest1 netwerk/protocol/http/nsHttpChannel.cpp:7530
8 xul.dll mozilla::net::nsHttpChannel::OnStartRequest netwerk/protocol/http/nsHttpChannel.cpp:7502
9 xul.dll nsInputStreamPump::OnInputStreamReady netwerk/base/nsInputStreamPump.cpp:429

=============================================================
crashes started using  	20181118220115 - recent regression, would be good to look at.  OTOH, this is a very low rate crash.
Priority: -- → P2
Whiteboard: [necko-triaged]
Valentin- can you have a look please?
Assignee: nobody → valentin.gosu
Flags: needinfo?(valentin.gosu)
So, the three crashes at https://bit.ly/2Tr7qNO seem to all be on the same machine.
The code attempts to serialize a cache header that appears to be corrupted - its variety is listed on all 3 crashes as 1530137995, and all pointers look the same in all 3 crashes, even though one of them has a different install time.
My guess would be that the cache entry was corrupted somehow, either in memory or on disk, and trying to reuse it caused Firefox to crash. None since that day, so presumably the user cleared their cache :)

There are some older crashes that have more or less the same signature, but slightly different causes.
For example, the crashes on 63.0: https://crash-stats.mozilla.com/report/index/d915db3a-00a4-4522-95fe-1da060181030 crashes at https://searchfox.org/mozilla-central/rev/adcc169dcf58c2e45ba65c4ed5661d666fc3ac74/ipc/chromium/src/base/pickle.cc#499

on 62.0.3 https://crash-stats.mozilla.com/report/index/42a58dea-6d77-4230-b3e2-76e0b0181022 it crashes on aParam.headerNameOriginal.IsEmpty() in ParamTraits<mozilla::net::nsHttpHeaderArray::nsEntry>::Write.

So, I don't know if this is _really_ a regression. It's pretty low volume, and at the moment we can't do much about it. I'll keep an eye on it, in case it spikes.
Flags: needinfo?(valentin.gosu)
Priority: P2 → P3
(In reply to Valentin Gosu [:valentin] from comment #3)
> So, the three crashes at https://bit.ly/2Tr7qNO seem to all be on the same
> machine.
> The code attempts to serialize a cache header that appears to be corrupted -
> its variety is listed on all 3 crashes as 1530137995, and all pointers look
> the same in all 3 crashes, even though one of them has a different install
> time.
> My guess would be that the cache entry was corrupted somehow, either in
> memory or on disk, and trying to reuse it caused Firefox to crash. None
> since that day, so presumably the user cleared their cache :)

I have not look at the code, but I will ask: can we do something in the cache code or somewhere else to avoid crashing?
I am asking because you wrote that you guess that the cache entry was corrupted.
Flags: needinfo?(valentin.gosu)
From what I can tell, we do have some code to make sure entries on disk aren't corrupted when we load them - not sure if they would definitely catch this. But the more likely version is that they get corrupted in memory, maybe not even by necko code :|
Flags: needinfo?(valentin.gosu)
Low volume crash, has a priority set. 
Marking fix-optional to remove this from regression triage. 
Happy to still take a patch in nightly.
Assignee: valentin.gosu → nobody
You need to log in before you can comment on or make changes to this bug.