1362984 - Crash in mozilla::net::nsHttpConnectionMgr::OnMsgReclaimConnection

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Comment 2

[Dragana Damjanovic [:dragana]]

These are strange crashes. I do not know what is gong wrong.
I notice that all have:
LavasoftTcpService64.dll

Comment 3

[Dragana Damjanovic [:dragana]]

PLDHashTable::Search | nsClassHashtable<T>::Get | mozilla::net::nsHttpConnectionMgr::OnMsgReschedTransaction

Comment 4

[Dragana Damjanovic [:dragana]]

Patrick, do you have a clue how this crashes can happen? there is always a reference to connection and nsHttpConnectionInfo as well...

Me staring at the code does not help at the moment :)

Comment 5

[Patrick McManus [:mcmanus]]

https://crash-stats.mozilla.com/report/index/9fd61745-cdc0-4b16-8860-0498f0170508

its the first thing that function does.. is it possible we're partially shutdown and related to a looong tfo caused timeout?

Comment 6

[Patrick McManus [:mcmanus]]

I'm not buying my own shutdown suggestion :) 

lavasoft appears to be some kind of antivirus dll with a free version. I guess installing it (on a vm) makes sense.. my desktop and its vm is out of commission until the end of the week (hardware failure).

Comment 7

[Dragana Damjanovic [:dragana]]

(In reply to Patrick McManus [:mcmanus] from comment #6)
> I'm not buying my own shutdown suggestion :) 
> 
> lavasoft appears to be some kind of antivirus dll with a free version. I
> guess installing it (on a vm) makes sense.. my desktop and its vm is out of
> commission until the end of the week (hardware failure).

I have install it, and everything runs normal. No crashes. The important part the "Web and network protection" in this software is not free, so probably I will not be able to reproduce it.

Comment 8

[Dragana Damjanovic [:dragana]]

I have upgrade the antivirus program, but still nothings happening :(

Comment 9

[Dragana Damjanovic [:dragana]]

This crashes happen after call to:
nsHttpConectionMgr::ReclaimConnection

This is only called in the destructor of ConnectionHandle

a nsAHttpTranaction hold reference to ConnectionHandle and reference is remove then a transaction gets canceled.

The TFO patches created some additional connections that sometime get canceled. The patches relay on nsHttpConectionMgr::ReclaimConnection to remove this connections(the connections cannot be reused so they will be removed).
I expect that this additional ReclaimConnection cause this crashes. I cannot prove it because ReclaimConnection dispatches a OnMsgReclaimConnection which crashes, so stack does not show from where was this dispatched.

I could make a work around to avoid using ReclaimConnection. I need to hold reference to ConnectionHandle and call Reset before destroying it.

Comment 10

[Marcia Knous [:marcia]]

Now that the pref is enabled again, have seen a few crashes in [@ mozilla::net::nsHttpConnectionMgr::OnMsgReclaimConnection]  using 20170531030204.

Comment 11

[Dragana Damjanovic [:dragana]]

Most of this crashes have conn pointer being null. I think this is fixed by bug 1369509.(need to run tests to confirm it)

there an interesting crash:
https://crash-stats.mozilla.com/report/index/47e0a363-8366-44fd-9371-61bb30170702

looking at stack, the values of nsConnectionEntry is corrupted, length of mActiveConns array is 1946182912(0x74006500) and capacity is 1912632576(0x72007500) which is too high. This is crash with a build from 20170630 where tfo is turned off. This probebly a latent bug (similar crashes occur in many older versions).

Comment 12

[Marcia Knous [:marcia]]

I didn't file a new bug, but [@ PLDHashTable::Search | nsRefPtrHashtable<T>::GetWeak | mozilla::net::nsHttpConnectionMgr::OnMsgReclaimConnection is another signature I see in crash stats that looks possibly related to this bug.

Comment 13

[Dragana Damjanovic [:dragana]]

Fixed by bug 1363372