Crash reports mentioning nsHttpTransaction

NEW
Unassigned

Status

()

Core
Networking
P3
normal
2 years ago
2 months ago

People

(Reporter: valentin, Unassigned)

Tracking

(Depends on: 2 bugs)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-backlog])

(Reporter)

Description

2 years ago
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.
valentin, can you update?
Whiteboard: [necko-backlog]
Assignee: nobody → valentin.gosu
Whiteboard: [necko-backlog] → [necko-active]
(Reporter)

Comment 2

2 years ago
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.
Depends on: 1153929, 1193389
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?
Workaround is working, not crashing at present, so --> backlog
Assignee: valentin.gosu → nobody
Whiteboard: [necko-active] → [necko-backlog]

Updated

4 months ago
Depends on: 1384725
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
You need to log in before you can comment on or make changes to this bug.