1095496 - [e10s] Assertion failure: mUsedShmems.empty(), at gfx/layers/ipc/ISurfaceAllocator.cpp

Status: RESOLVED WORKSFORME

(Core Graveyard :: Tracking, defect)

Description

[Mike de Boer [:mikedeboer]]

Attachment: e10s_crashlog_1.txt

Sorry for the very bad Summary, please feel free to update it if the following log makes sense to you (attached to issue).

I only did the following:
 * opened the most recent fx-team
 * opened the Loop/ Hello panel and waited until I saw the share URL in the input box
 * Opened a new window (CMD+N)
 * Opened the Loop panel there too.
 * Closed the newly opened window (CMD+W)
 * Opened the Loop panel again in the previous window... BOOM!

Note: I _might_ have had the Browser Console open at that time. Not sure.

I'm available for direct feedback/ questions in #developers or #fx-team.

Comment 1

[Chris Peterson [:cpeterson]]

Mike: do you have any add-ons installed?

This is an gfx assertion failure:

> Assertion failure: mUsedShmems.empty(), at /Users/mikedeboer/Projects/fx-team/gfx/layers/ipc/ISurfaceAllocator.cpp:53
> #01: mozilla::AtomicRefCountedWithFinalize<mozilla::layers::ISurfaceAllocator>::Release()[/Users/mikedeboer/Projects/fx-team/obj-x86_64-apple-darwin14.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0xb9e5d6]
> #02: mozilla::layers::TextureChild::~TextureChild()[/Users/mikedeboer/Projects/fx-team/obj-x86_64-apple-darwin14.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0xc05be2]
> #03: mozilla::layers::TextureChild::Release()[/Users/mikedeboer/Projects/fx-team/obj-x86_64-apple-darwin14.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0xc05d90]
> #04: mozilla::layers::TextureClient::DestroyIPDLActor(mozilla::layers::PTextureChild*)[/Users/mikedeboer/Projects/fx-team/obj-x86_64-apple-darwin14.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0xc00558]
> #05: mozilla::layers::PLayerTransactionChild::RemoveManagee(int, mozilla::ipc::IProtocol*)[/Users/mikedeboer/Projects/fx-team/obj-x86_64-apple-darwin14.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x695be3]
> #06: mozilla::layers::PTextureChild::OnMessageReceived(IPC::Message const&)[/Users/mikedeboer/Projects/fx-team/obj-x86_64-apple-darwin14.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x79d360]

Followed by an animation assertion failure:

> Assertion failure: !GetLocalTime().IsNull() (Getting the value portion of an animation that's not being sampled), at /Users/mikedeboer/Projects/fx-team/layout/style/nsTransitionManager.cpp:51
> #01: nsTransitionManager::StyleContextChanged(mozilla::dom::Element*, nsStyleContext*, nsStyleContext*)[/Users/mikedeboer/Projects/fx-team/obj-x86_64-apple-darwin14.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x248e9c2]

Comment 2

[Mike de Boer [:mikedeboer]]

(In reply to Chris Peterson (:cpeterson) from comment #1)
> Mike: do you have any add-ons installed?

Nope, this was on a blank profile.

Comment 3

[Milan Sreckovic [:milan] (needinfo for best results)]

I'm sure :nical or :sotaro can give us their thoughts.  Mike, has it happened since?  I'm assuming this was on the current nightly at the time?

Comment 4

[Mike de Boer [:mikedeboer]]

Hasn't happened since and I was running a fresh local build (integration/fx-team) that day.

Comment 5

[Nicolas Silva [:nical]]

This assertion usually indicates that we leaked a tile's lock or that a tile is still alive when we reach the destruction of the ISurfaceAllocator (which is usually happening late in the shutdown).

Comment 6

[Sotaro Ikeda [:sotaro]]

This say that there is a suspect leak of shmem that is used for tile's lock. But this assertion could also be hit when TextureClient is destoryed even when TiledContentHost is still using TextureHost and the tile's lock.

Comment 7

[Mason Chang [Inactive] [:mchang]]

I'm able to reproduce this pretty easily on e10s on OS X Yosemite with a debug build.

STR:
1) Load Nightly
2) Open a new window (2 Windows total)
3) In the new window, load yahoo.com.
4) While yahoo.com is still loading, close the window
5) Wait a couple of seconds for the error.

Tested on Gecko 219960:8401afdb6e6c

Comment 8

[Mason Chang [Inactive] [:mchang]]

Attachment: e10s crash stack

Comment 9

[Mike Conley (:mconley) (:⚙️)]

I am also easily able to reproduce this in a debug build on OS X on Mountain Lion using the steps in comment 7.

Re-nomming.

Comment 10

[Milan Sreckovic [:milan] (needinfo for best results)]

Mason, since you can reproduce this, can you take a look at comment 5 and comment 6 and add some instrumenting to find out which of these two is happening?

Comment 12

[Milan Sreckovic [:milan] (needinfo for best results)]

I'm seeing this, intermittently, but seemingly consistently per "build" - once I make some unrelated changes and recompile, the crash may or may not be there, but once I have a build that crashes, it crashes all the time.  Slightly different stack, see bug 1162536, and the shmem count is 1 at the time of the crash.

Comment 13

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: crash stack on window close

This happens consistently for me on trunk on OSX 10.9.5 with these STRs:

1. Go to http://jsfiddle.net
2. Close window.

Comment 14

[Blake Kaplan (:mrbkap) (inactive)]

If we're going to turn on e10s tests for OSX, this is going to block us. Given that this is low priority to debug and fix, can we get rid of the assertion in the meantime?

Comment 15

[Milan Sreckovic [:milan] (needinfo for best results)]

Mason, no luck with extra instrumentation?

Comment 16

[Mason Chang [Inactive] [:mchang]]

I haven't looked at this in a while. Still waiting on nical to see if we can delete this assertion for now.

Comment 17

[Nicolas Silva [:nical]]

(In reply to Mason Chang [:mchang] from comment #16)
> I haven't looked at this in a while. Still waiting on nical to see if we can
> delete this assertion for now.

The assertion is symptomatic of a real issue (either a leak, or wrong shutdown ordering). Usually our stance is to keep these assertions. Now, if we are all busy on higher priority bugs and this is tempering with a lot of people's productivity, it's probably ok to make it a warning for now.

Comment 18

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to Blake Kaplan (:mrbkap) (please use needinfo!) from comment #14)
> If we're going to turn on e10s tests for OSX, this is going to block us.
> Given that this is low priority to debug and fix, can we get rid of the
> assertion in the meantime?

Blake, as soon as this is the last thing blocking you, yes, please just comment out the assertion and open a bug for Core:Graphics (CC me on it) for us to find the real fix.  Thanks!

Comment 19

[Blake Kaplan (:mrbkap) (inactive)]

I haven't seen this in a while. It seems like it might have been fixed along the way.

Comment 20

[Milan Sreckovic [:milan] (needinfo for best results)]

Let's reopen if it comes back.