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?
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.
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.
https://crash-stats.mozilla.com/report/index/bp-68d03ffd-3b40-45cc-bdae-bc1b72140217 https://crash-stats.mozilla.com/report/index/bp-2e26ef29-ec12-4b29-90d7-14f222140217 https://crash-stats.mozilla.com/report/index/bp-43688a16-96f6-4b67-adea-70e232140217 https://crash-stats.mozilla.com/report/index/bp-f942e4e6-3f6c-4b1c-bcee-d68b42140217 https://crash-stats.mozilla.com/report/index/bp-fe6fa294-d9b5-40f0-a348-c72ed2140217 I have the Problem to since the latest nightly. Every Restart (with an new profile to) crashes the nightly
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/
backout 905460 remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/4f9f58d41eac
Assignee: nobody → mcmanus
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
This should be uplift to Aurora29.0a2
Oops, not affected to Aurora29.0a2
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.