Closed Bug 973207 Opened 7 years ago Closed 7 years ago

Crash in nsHttpConnection::Close with poisoned memory


(Core :: Networking: HTTP, defect)

Not set



Tracking Status
firefox28 --- unaffected
firefox29 --- unaffected
firefox30 --- verified


(Reporter: benjamin, Assigned: mcmanus)



(Keywords: crash, regression)

Crash Data

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

See 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

The caller at 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.
Duplicate of this bug: 973608
Assignee: nobody → mcmanus
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
This should be uplift to Aurora29.0a2
Keywords: crash, regression
OS: Windows 7 → All
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.
Crash Signature: [@ mozilla::net::nsHttpConnection::Close(tag_nsresult) ] → [@ mozilla::net::nsHttpConnection::Close(tag_nsresult) ] [@ nsRefPtr<nsIRunnable>::~nsRefPtr<nsIRunnable>() | nsSocketInputStream::OnSocketReady(tag_nsresult) ]
You need to log in before you can comment on or make changes to this bug.