1049513 - crash in nsRefPtr<mozilla::dom::SpeechGrammar>::assign_with_AddRef(mozilla::dom::SpeechGrammar*) | mozilla::net::nsHttpChannel::OnStopRequest(nsIRequest*, nsISupports*, tag_nsresult)

Status: RESOLVED INCOMPLETE

(Core :: Networking, defect)

Description

[David Bolter [:davidb] (NeedInfo me for attention)]

This bug was filed from the Socorro interface and is 
report bp-85385c2f-1fc7-489a-b4de-1dacf2140805.
=============================================================

Probably a UAF. Looks similar to bug 1037218. Filing so we can decide together if it is a dupe. Probably together with bug 1011354, and bug 1033443 this should get some attention.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Yeah,  	nsRefPtr<mozilla::dom::SpeechGrammar>::assign_with_AddRef(mozilla::dom::SpeechGrammar*) part in the stack doesn't make sense.

Comment 2

[Andrew McCreight [:mccr8]]

David, can you maybe try to debogus the stacks of one of these crashes, if it isn't too much of a pain?  It might make this slightly less unactionable.  Thanks.

Comment 3

[(Away)]

The AddRef is failing because mTransaction->Connection() is dead here: http://hg.mozilla.org/mozilla-central/file/843332cc69af/netwerk/protocol/http/nsHttpChannel.cpp#l5088

xul!nsRefPtr<mozilla::dom::MessagePort>::assign_with_AddRef
xul!mozilla::net::nsHttpChannel::OnStopRequest
xul!nsInputStreamPump::OnStateStop
xul!nsInputStreamPump::OnInputStreamReady
xul!nsInputStreamReadyEvent::Run
xul!nsThread::ProcessNextEvent
xul!NS_ProcessNextEvent
xul!mozilla::ipc::MessagePump::Run
xul!MessageLoop::RunHandler
xul!MessageLoop::Run
xul!nsBaseAppShell::Run
xul!nsAppShell::Run
xul!XREMain::XRE_mainRun
xul!XREMain::XRE_main
xul!XRE_main
firefox!do_main
firefox!NS_internal_main
firefox!wmain
firefox!__tmainCRTStartup
kernel32!BaseThreadInitThunk
ntdll!__RtlUserThreadStart
ntdll!_RtlUserThreadStart

I'm pretty sure I've seen OnStopRequest before, but my search can't seem to find it. Some of these may be related (or not -- OnStopRequest is pretty big so these may be different):

https://crash-stats.mozilla.com/search/?signature=~nsHttpChannel%3A%3AOnStopRequest&address=%240x5a5a&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform

Comment 4

[Patrick McManus [:mcmanus]]

onstoprequest is often called on a listening object after a fair bit of delay during network activity.. so when the listening object has a reference counting problem independent of necko and gets freed early it will often not show up until onstoprequest is called.. unfortunately that doesn't really help figure out where the problem is because the root problem (dropping too many references outside of necko) has already happened before the reported stack trace is taken.

I'm not saying that's absolutely the issue with speech grammar here, but it often is.

Comment 5

[(Away)]

(In reply to Olli Pettay [:smaug] from comment #1)
> Yeah,  
> nsRefPtr<mozilla::dom::SpeechGrammar>::assign_with_AddRef(mozilla::dom::
> SpeechGrammar*) part in the stack doesn't make sense.

(In reply to Patrick McManus [:mcmanus] from comment #4)
> I'm not saying that's absolutely the issue with speech grammar here, but it
> often is.

It's probably not a SpeechGrammar. As an optimization, the linker folds together functions with identical disassembly, which often happens with smart pointers. All assign_with_AddRef<T*> look the same.