Crash in nsHttpConnection::Close with poisoned memory

VERIFIED FIXED in Firefox 30

Status

()

defect
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: benjamin, Assigned: mcmanus)

Tracking

({crash, regression})

unspecified
mozilla30
x86
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox28 unaffected, firefox29 unaffected, firefox30 verified)

Details

(crash signature)

See bp-1d4d6260-0461-435e-b517-eb2b92140215

See https://crash-stats.mozilla.com/report/list?signature=mozilla::net::nsHttpConnection::Close%28tag_nsresult%29#tab-reports for a list of more.

I found this because memory poisoning landed in today's nightly and the crashes here are at the poison address 0x5a5a5a5a. However, this crash signature appears to have started only in yesterday's nightly anyway, so it may be a new regression.

The crashes are all at http://hg.mozilla.org/mozilla-central/annotate/b80f7eece913/netwerk/protocol/http/nsHttpConnection.cpp#l509

The caller at http://hg.mozilla.org/mozilla-central/annotate/b80f7eece913/netwerk/protocol/http/nsHttpConnectionMgr.cpp#l897 holds a strong reference to the nsHttpConnection, so I don't expect that we're destroying `this` but that's what it kinda looks like.

dmajor can you load a minidump and identify exactly what pointer we're dereferencing when the crash happens?
Flags: needinfo?(dmajor)
Yes, it is strange that this is happening with the strong reference. The mSocketTransport member is 0x5a5a5a5a. The deref was trying to get its vtable pointer for the Close call -- which means it must have been still alive for the SetSecurityCallbacks call immediately before.

Even the amd64 crashes are at 0x5a5a5a5a`5a5a5a5a (but the site shows 0xffffffff?). Some of them are dereferencing mSocketTransport but others are crashing a little earlier on mTCPKeepaliveTransitionTimer.

In every dump I see one or two threads waiting in arena_dalloc. Suspicious? Or maybe that's normal given how many threads we always have, I guess I never really paid attention.
Flags: needinfo?(dmajor)
there's a good chance that's a bug from 905460 which just landed - ironically that whole patch is about reference counting these objects more safely :)

I don't know if I'll be able to get to it before wed or not.. can be backed out if its top crasher material.
Blocks: 905460
Hint: For me it happens only if I am logged in in a page which requires authentication (MS Sharepoint). Unfortunately I can not share the source of the page (sensitive informations).
If more information about the page is needed I can try to extract it.
that's useful information - its using windows sticky auth no doubt
could be a reason. For me it is the camp-firefox.
http://www.camp-firefox.de/forum/
Duplicate of this bug: 973608
https://hg.mozilla.org/mozilla-central/rev/4f9f58d41eac
Assignee: nobody → mcmanus
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
This should be uplift to Aurora29.0a2
Keywords: crash, regression
OS: Windows 7 → All
Oops, 
not affected to Aurora29.0a2
Duplicate of this bug: 973912
20140217 were the last Nightly builds with reports of this crash.  VERIFIED based on no crashes since then.
Status: RESOLVED → VERIFIED
Crash Signature: [@ mozilla::net::nsHttpConnection::Close(tag_nsresult) ] → [@ mozilla::net::nsHttpConnection::Close(tag_nsresult) ] [@ nsRefPtr<nsIRunnable>::~nsRefPtr<nsIRunnable>() | nsSocketInputStream::OnSocketReady(tag_nsresult) ]
Duplicate of this bug: 973845
You need to log in before you can comment on or make changes to this bug.