1196787 - Crash reports mentioning nsHttpTransaction

Status: RESOLVED INACTIVE

(Core :: Networking, defect, P3)

Description

[Valentin Gosu [:valentin] (he/him)]

Firefox 41.0b1 Crash Report [@ nsCOMPtr_base::~nsCOMPtr_base() | mozilla::net::nsHttpTransaction::~nsHttpTransaction() ]
https://crash-stats.mozilla.com/report/index/a4dcdbc6-33c2-403a-99b6-4cfa62150815
// address 0x5a5a5a5a // double free?

Firefox 41.0b1 Crash Report [@ nsCOMPtr_base::assign_with_AddRef(nsISupports*) | mozilla::net::nsHttpTransaction::Close(nsresult) ]
https://crash-stats.mozilla.com/report/index/4b2f3ac2-0432-4d32-af56-d68fd2150816
// mPipeOut->CloseWithStatus(reason); works
// mPipeOut = nullptr crashes.

Firefox 41.0b1 Crash Report [@ msvcr120.dll@0xf189 | mozilla::net::nsHttpTransaction::ProcessData(char*, unsigned int, unsigned int*) ]
https://crash-stats.mozilla.com/report/index/5cfde634-b65a-4c95-9f25-e0ea32150818
// seems like a corrupted stack trace

Firefox 41.0b1 Crash Report [@ PR_Unlock | mozilla::net::nsHttpTransaction::SetResponseStart(mozilla::TimeStamp, bool) ]
https://crash-stats.mozilla.com/report/index/b61df0d4-19fe-4ff3-b3cb-ea2f82150816
// WritePipeSegment -> nsHttpTransaction::SetResponseStart -> PR_Unlock?
// does the transaction go away while locked?

Firefox 41.0b1 Crash Report [@ mozilla::net::nsHttpTransaction::Init(unsigned int, mozilla::net::nsHttpConnectionInfo*, mozilla::net::nsHttpRequestHead*, nsIInputStream*, bool, nsIEventTarget*, nsIInterfaceRequestor*, nsITransportEventSink*, nsIAsyncInputStream**) ]
https://crash-stats.mozilla.com/report/index/7edbc948-3246-483f-bb0a-d9ae02150817
// This is odd. Does it crash for requestHead->PeekHeader?

Firefox 41.0b1 Crash Report [@ nsCOMPtr_base::~nsCOMPtr_base() | mozilla::net::nsHttpTransaction::~nsHttpTransaction() ]
https://crash-stats.mozilla.com/report/index/4905abb7-8cbd-4476-90ed-fc4292150815

Firefox 41.0b1 Crash Report [@ @0x0 | mozilla::net::nsHttpTransaction::Init(unsigned int, mozilla::net::nsHttpConnectionInfo*, mozilla::net::nsHttpRequestHead*, nsIInputStream*, bool, nsIEventTarget*, nsIInterfaceRequestor*, nsITransportEventSink*, nsIAsyncInputStream**) ]
https://crash-stats.mozilla.com/report/index/0c7d2005-32b1-4443-8552-659562150818
// http://hg.mozilla.org/releases/mozilla-beta/annotate/be2423a7ec20/netwerk/protocol/http/nsHttpTransaction.cpp#l381
// This fails in NS_NewPipe2

https://crash-stats.mozilla.com/report/list?signature=nsCOMPtr_base%3A%3A~nsCOMPtr_base%28%29+|+mozilla%3A%3Anet%3A%3AnsHttpTransaction%3A%3A~nsHttpTransaction%28%29&range_value=28&range_unit=days&date=2015-08-20#tab-reports
// List of crashes in nsHttpTransactionDestructor at various addresses in the past 20 days.

Comment 1

[Patrick McManus [:mcmanus]]

valentin, can you update?

Comment 2

[Valentin Gosu [:valentin] (he/him)]

Crashes mentioning nsHttpTransaction in the past 60 days:

https://crash-stats.mozilla.com/search/?signature=~nsHttpTransaction&date=%3E%3D2016-01-01&date=%3C%3D2016-02-28&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature

mozilla::net::nsHttpTransaction::WriteSegments - 6280 crashes
nsCOMPtr_base::~nsCOMPtr_base | mozilla::net::nsHttpTransaction::~nsHttpTransaction - 2155 crashes
mozilla::net::nsHttpTransaction::Close - 454 crashes
mozilla::net::nsHttpTransaction::Caps - 379 crashes
mozilla::net::nsHttpTransaction::~nsHttpTransaction  - 123 crashes
mozilla::net::nsHttpTransaction::ProcessData - 100 crashes

It's very difficult to trace where the corruption occurs. There are even some crashes in nsHttpTransaction::Init.

Comment 3

[Dragana Damjanovic [:dragana]]

I had an idea today. We can duplicate some class members, like mPipeOut, mPipeIn, maybe headers in nsHttpConnection (bug 1250816 and bug  1247982) and do a check at the beginning and at the end of each function. And run  this on nightly for some days. I was thinking maybe there is a pattern when the corruption happens, maybe that would help.

Any other suggestion?

Comment 4

[Jason Duell]

Workaround is working, not crashing at present, so --> backlog

Comment 5

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 6

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258