1665787 - Crash in [@ mozilla::UniquePtr<T>::reset] called from PBackgroundIDBVersionChangeTransactionParent

Status: RESOLVED INCOMPLETE

(Core :: XPCOM, defect)

Description

[Andrew McCreight [:mccr8]]

Crash report: https://crash-stats.mozilla.org/report/index/7e93bb78-657c-47d1-8925-998190200916

Top 10 frames of crashing thread:

0 xul.dll mozilla::UniquePtr<mozilla::net::nsHttpResponseHead, mozilla::DefaultDelete<mozilla::net::nsHttpResponseHead> >::reset mfbt/UniquePtr.h:304
1 xul.dll mozilla::net::HttpBaseChannel::~HttpBaseChannel netwerk/protocol/http/HttpBaseChannel.cpp:267
2 xul.dll mozilla::net::HttpChannelChild::~HttpChannelChild netwerk/protocol/http/HttpChannelChild.cpp:259
3 xul.dll mozilla::net::HttpChannelChild::Release netwerk/protocol/http/HttpChannelChild.cpp:320
4 xul.dll mozilla::dom::indexedDB::PBackgroundIDBVersionChangeTransactionParent::ActorDealloc ipc/ipdl/_ipdlheaders/mozilla/dom/indexedDB/PBackgroundIDBVersionChangeTransactionParent.h:353
5 xul.dll mozilla::ipc::ActorLifecycleProxy::~ActorLifecycleProxy ipc/glue/ProtocolUtils.cpp:276
6 xul.dll mozilla::dom::PContentChild::OnMessageReceived ipc/ipdl/PContentChild.cpp:8546
7 xul.dll mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2074
8 xul.dll mozilla::ipc::MessageChannel::MessageTask::Run ipc/glue/MessageChannel.cpp:1953
9 xul.dll mozilla::SchedulerGroup::Runnable::Run xpcom/threads/SchedulerGroup.cpp:146

I'm not sure what is going on here. The stacks say PBackgroundIDBVersionChangeTransactionParent, but that's a trivial function so LTO might be combining the dealloc methods.

There's about 40 crashes with this signature and PBackgroundIDBVersionChangeTransactionParent in the proto signature, on 80.0.1 and 82.0a1.

There are quite a few Flash sites in the URLs, including http://www.mousecity.com/games/point-and-click/snowday/ http://homestarrunner.com/ https://helpx.adobe.com/flash-player.html

Comment 1

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

It looks like this is how we're crashing, at least for the ones with a crash address of 0xfffffff8:

   0x10b5fed0:     movzwl 0x14(%esi),%ecx
   0x10b5fed4:     mov    0xc(%esi),%eax
   0x10b5fed7:     test   $0x4,%cl
   0x10b5feda:     jne    0x10b5ff22      # this branch is taken
…
   0x10b5ff20:     jmp    0x10b5fed0
   0x10b5ff22:     lock decl -0x8(%eax)

So we load a 16-bit flags field, and if the 4 bit is set then we atomically decrement something at a negative offset from a pointer, probably during a destructor. Sounds familiar: this is an XPCOM refcounted string, probably one of the fields of nsHttpResponseHead (assuming that part of the stack is accurate), but the pointer has become null.

I don't know how the string got into that state, but it's probably not IPC's fault?

Comment 2

[Julien Cristau [:jcristau]]

Updating signature as mozilla::UniquePtr<T>::reset was added to the prefix list.

Comment 3

[Nika Layzell [:nika] (ni? for response)]

Looks like all of the crashes are on old versions of firefox, and there have been none on recent versions. Marking as incomplete for now.