"ABORT: Shadow layers can't be destroyed during txns!: '!HasShadow() || !BasicManager()->InTransaction()" during layout/reftests/reftest-sanity/zoom-invalidation.html

RESOLVED FIXED

Status

()

RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: cjones, Assigned: cjones)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

This isn't 100% reproducible, but still reproducible with high frequency, maybe 75% or so.  I haven't run reftest-ipc for quite some time, and I don't have any idea off-hand what might have regressed this.

This would block bug 623613, except that I don't think we make debug builds for mobile platforms yet.

#10 0x00007feec3ddcd04 in mozilla::layers::BasicShadowableThebesLayer::~BasicShadowableThebesLayer (this=0x7feeb0105920, __in_chrg=<value optimized out>) at /home/cjones/mozilla/mozilla-central/gfx/layers/basic/BasicLayers.cpp:1746
#11 0x00007feec267748a in mozilla::layers::Layer::Release (this=0x7feeb0105920) at ../../dist/include/Layers.h:511
#12 0x00007feec2677f95 in nsRefPtr<mozilla::layers::Layer>::~nsRefPtr (this=0x1ff9128, __in_chrg=<value optimized out>) at ../../dist/include/nsAutoPtr.h:969
#13 0x00007feec2677e34 in mozilla::FrameLayerBuilder::DisplayItemData::~DisplayItemData (this=0x1ff9128, __in_chrg=<value optimized out>) at /home/cjones/mozilla/mozilla-central/layout/base/FrameLayerBuilder.h:365
#14 0x00007feec267bdf3 in nsTArrayElementTraits<mozilla::FrameLayerBuilder::DisplayItemData>::Destruct (e=0x1ff9128) at ../../dist/include/nsTArray.h:279
#15 0x00007feec267b893 in nsTArray<mozilla::FrameLayerBuilder::DisplayItemData, nsTArrayDefaultAllocator>::DestructRange (this=0x7fffc4e31f50, start=0, count=1) at ../../dist/include/nsTArray.h:1106
#16 0x00007feec267aafa in nsTArray<mozilla::FrameLayerBuilder::DisplayItemData, nsTArrayDefaultAllocator>::RemoveElementsAt (this=0x7fffc4e31f50, start=0, count=1) at ../../dist/include/nsTArray.h:834
#17 0x00007feec267974f in nsTArray<mozilla::FrameLayerBuilder::DisplayItemData, nsTArrayDefaultAllocator>::Clear (this=0x7fffc4e31f50) at ../../dist/include/nsTArray.h:845
#18 0x00007feec267813e in nsTArray<mozilla::FrameLayerBuilder::DisplayItemData, nsTArrayDefaultAllocator>::~nsTArray (this=0x7fffc4e31f50, __in_chrg=<value optimized out>) at ../../dist/include/nsTArray.h:373
#19 0x00007feec266f0f2 in mozilla::FrameLayerBuilder::InternalDestroyDisplayItemData (aFrame=0x20b6688, aPropertyValue=0x1ff9120, aRemoveFromFramesWithLayers=0) at /home/cjones/mozilla/mozilla-central/layout/base/FrameLayerBuilder.cpp:455
#20 0x00007feec266f47d in mozilla::FrameLayerBuilder::UpdateDisplayItemDataForFrame (aEntry=0x7feeb012c170, aUserArg=0x7fffc4e324f0) at /home/cjones/mozilla/mozilla-central/layout/base/FrameLayerBuilder.cpp:557
#21 0x00007feec26798ec in nsTHashtable<nsPtrHashKey<nsIFrame> >::s_EnumStub (table=0x7feeb00cd978, entry=0x7feeb012c170, number=2, arg=0x7fffc4e32110) at ../../dist/include/nsTHashtable.h:420
#22 0x00007feec3bf6e17 in PL_DHashTableEnumerate (table=0x7feeb00cd978, etor=0x7feec26798ba <nsTHashtable<nsPtrHashKey<nsIFrame> >::s_EnumStub(PLDHashTable*, PLDHashEntryHdr*, PRUint32, void*)>, arg=0x7fffc4e32110) at pldhash.c:754
#23 0x00007feec26783c1 in nsTHashtable<nsPtrHashKey<nsIFrame> >::EnumerateEntries (this=0x7feeb00cd978, enumFunc=0x7feec266f384 <mozilla::FrameLayerBuilder::UpdateDisplayItemDataForFrame(nsPtrHashKey<nsIFrame>*, void*)>, userArg=0x7fffc4e324f0) at ../../dist/include/nsTHashtable.h:241
#24 0x00007feec266f2b9 in mozilla::FrameLayerBuilder::WillEndTransaction (this=0x7fffc4e324f0, aManager=0x1cecee0) at /home/cjones/mozilla/mozilla-central/layout/base/FrameLayerBuilder.cpp:521
#25 0x00007feec26c52f9 in nsDisplayList::PaintForFrame (this=0x7fffc4e32340, aBuilder=0x7fffc4e324f0, aCtx=0x0, aForFrame=0x1fda7e8, aFlags=5) at /home/cjones/mozilla/mozilla-central/layout/base/nsDisplayList.cpp:539
#26 0x00007feec26c4e12 in nsDisplayList::PaintRoot (this=0x7fffc4e32340, aBuilder=0x7fffc4e324f0, aCtx=0x0, aFlags=5) at /home/cjones/mozilla/mozilla-central/layout/base/nsDisplayList.cpp:460
#27 0x00007feec26f7a18 in nsLayoutUtils::PaintFrame (aRenderingContext=0x0, aFrame=0x1fda7e8, aDirtyRegion=..., aBackstop=4294967295, aFlags=260) at /home/cjones/mozilla/mozilla-central/layout/base/nsLayoutUtils.cpp:1564
#28 0x00007feec27230f2 in PresShell::Paint (this=0x2094420, aDisplayRoot=0x1fd4aa0, aViewToPaint=0x1fd4aa0, aWidgetToPaint=0x1cb4100, aDirtyRegion=..., aIntDirtyRegion=..., aPaintDefaultBackground=0, aWillSendDidPaint=0) at /home/cjones/mozilla/mozilla-central/layout/base/nsPresShell.cpp:6203
Not too surprisingly, we seem to be unlinking a layer from the layer tree that's not protected by the keepalive array

(gdb) ptarray this->mManager->mKeepAlive
elem[0]: $7 = {
  mRawPtr = 0x1ce4620
}
elem[1]: $8 = {
  mRawPtr = 0x1ce48e0
}
elem[2]: $9 = {
  mRawPtr = 0x1ce48e0
}
elem[3]: $10 = {
  mRawPtr = 0x1ce48e0
}
elem[4]: $11 = {
  mRawPtr = 0x1ce48e0
}
elem[5]: $12 = {
  mRawPtr = 0x1ce48e0
}
elem[6]: $13 = {
  mRawPtr = 0x1ce4620
}
elem[7]: $14 = {
  mRawPtr = 0x1ce4620
}
elem[8]: $15 = {
  mRawPtr = 0x1ce4620
}
elem[9]: $16 = {
  mRawPtr = 0x1ce4620
}
elem[10]: $17 = {
  mRawPtr = 0x20ed890
}
elem[11]: $18 = {
  mRawPtr = 0x1ce4620
}
nsTArray length = 12
nsTArray capacity = 16

(gdb) p *this->mShadow
$22 = (mozilla::layers::ShadowLayerChild) {
[snip]
  mLayer = 0x7feeb0105b00
Bisect sez

The first bad revision is:
changeset:   62248:e71960b6957c
user:        Alon Zakai <azakai@mozilla.com>
date:        Wed Feb 09 12:13:18 2011 -0800
summary:     Bug 610670 - Reuse a single puppet widget. r=bz,cjones a=blocking-fennec
Blocks: 610670
Created attachment 514568 [details] [diff] [review]
Remove assertion that's no longer asserting what it was intended to

This assertion was meant to prevent a shadowable layer from being destroyed in the middle of a transaction in which it was participating, because then the destroy message would race ahead of the transaction message and bad things would happen.  In the new world after bug 610670, though, this assertion is being tripped by layers being deleted during FrameLayerBuilder::WillEndTransaction in the middle of the *next* transaction after the one in which they were disconnected from the layer tree.  I'm not 100% sure why we're holding on to display item data longer, but this situation is perfectly fine.  However, this assertion can't distinguish this OK case from the bad case, and I don't know how to fix it to do so.

This assertion had a useful life, but the kinds of bugs it protects against should show up as crashers, and we should hopefully soon-ish be getting tinderbox coverage of shadow-layer code.  So I'm OK wishing this au revoir.
Assignee: nobody → jones.chris.g
Attachment #514568 - Flags: review?(roc)
Attachment #514568 - Flags: approval2.0?
Attachment #514568 - Flags: review?(roc)
Attachment #514568 - Flags: review+
Attachment #514568 - Flags: approval2.0?
Attachment #514568 - Flags: approval2.0+
http://hg.mozilla.org/mozilla-central/rev/7bebe6a7dcd0
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.