973207 - Crash in nsHttpConnection::Close with poisoned memory

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect)

Description

[Benjamin Smedberg]

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?

Comment 1

[(Away)]

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.

Comment 2

[Patrick McManus [:mcmanus]]

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.

Comment 3

[Lars Gusowski [:lagu]]

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

Comment 4

[Volkmar Kostka]

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.

Comment 5

[Patrick McManus [:mcmanus]]

that's useful information - its using windows sticky auth no doubt

Comment 6

[Lars Gusowski [:lagu]]

could be a reason. For me it is the camp-firefox.
http://www.camp-firefox.de/forum/

Comment 8

[Patrick McManus [:mcmanus]]

backout 905460
remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/4f9f58d41eac

Comment 9

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/4f9f58d41eac

Comment 10

[Alice0775 White]

This should be uplift to Aurora29.0a2

Comment 11

[Alice0775 White]

Oops, 
not affected to Aurora29.0a2

Comment 13

[Tracy Walker [:tracy]]

20140217 were the last Nightly builds with reports of this crash.  VERIFIED based on no crashes since then.