1120285 - crash with ProxyAccessible* in nsTArray_Impl<mozilla::dom::indexedDB::PBackgroundIDBCursorChild*, nsTArrayInfallibleAllocator>::Clear()

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[(Away)]

This bug was filed from the Socorro interface and is 
report bp-4f5e5668-ac1e-4a0b-8eb9-01f4e2150110.
=============================================================

The signature is misleading due to folding; it's actually an array of ProxyAccessible*. This began in build 20150110030201. Currently not super high volume but worth monitoring.

Comment 2

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

OK this should get top crash level attention (given bug 1120464 is a dupe).

Comment 3

[(Away)]

Looks like the Win64 variant got a different (but equally misleading) signature.

Comment 4

[Trevor Saunders (:tbsaunde)]

I need to run out for a while, but I believe the cause of this is bug 1113845 being incomplete.  ProxyAccessible::Shutdown on the outerdoc doesn't fail, but we later go to shutdown the child doc we crash.

Comment 5

[Trevor Saunders (:tbsaunde)]

Attachment: correctly shutdown outer doc accessible proxies

Comment 6

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

Comment on attachment 8548373 [details] [diff] [review]
correctly shutdown outer doc accessible proxies

Review of attachment 8548373 [details] [diff] [review]:
-----------------------------------------------------------------

r=me because topcrash, but with some uncomfortable shifting in my seat. If you don't comment here I'll follow up IRL.

::: accessible/ipc/DocAccessibleParent.h
@@ +48,5 @@
> +  void Destroy();
> +  virtual void ActorDestroy(ActorDestroyReason aWhy) MOZ_OVERRIDE
> +  {
> +    if (!mShutdown)
> +      Destroy();

Are you sure you need this check? When does it bite?

::: accessible/ipc/ProxyAccessible.cpp
@@ +26,5 @@
> +  } else {
> +    if (mChildren.Length() != 1)
> +      MOZ_CRASH("outer doc doesn't own adoc!");
> +
> +    static_cast<DocAccessibleParent*>(mChildren[0])->Destroy();

Hmmm... ah, right...

Comment 7

[Trevor Saunders (:tbsaunde)]

> ::: accessible/ipc/DocAccessibleParent.h
> @@ +48,5 @@
> > +  void Destroy();
> > +  virtual void ActorDestroy(ActorDestroyReason aWhy) MOZ_OVERRIDE
> > +  {
> > +    if (!mShutdown)
> > +      Destroy();
> 
> Are you sure you need this check? When does it bite?

Consider the problem case where the outer doc gets a hide before the doc it owns is destroyed.  In that case we know execute the guts of what was ActorDestroy when the outer doc is hidden.  That means when the document is eventually destroyed there's nothing left to do.

Comment 8

[Trevor Saunders (:tbsaunde)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/ce39fe1d44c5

Comment 9

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/ce39fe1d44c5

Comment 10

[(Away)]

comdat folding ftl

Comment 11

[Robert Kaiser]

(In reply to David Major [:dmajor] (UTC+13) from comment #10)
> comdat folding ftl

David, the "nsTArray_Impl<mozilla::layers::Layer*, nsTArrayInfallibleAllocator>::Clear()" signature is #5 on Dev Edition 37.0a2, do we need an uplift here or does the folding point to a different issue?

Comment 12

[Trevor Saunders (:tbsaunde)]

(In reply to Robert Kaiser (:[e-mail]) from comment #11)
> (In reply to David Major [:dmajor] (UTC+13) from comment #10)
> > comdat folding ftl
> 
> David, the "nsTArray_Impl<mozilla::layers::Layer*,
> nsTArrayInfallibleAllocator>::Clear()" signature is #5 on Dev Edition
> 37.0a2, do we need an uplift here or does the folding point to a different
> issue?

I think we should just take bug 1123842 to handle that

Comment 13

[(Away)]

This started on v37 nightlies so yeah it's on aurora now too. Sounds like bug 1123842 will do the trick.