If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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



Core Graveyard
3 years ago
a year ago


(Reporter: mikedeboer, Unassigned)


(Blocks: 2 bugs, {assertion, crash})

36 Branch
assertion, crash
Dependency tree / graph

Firefox Tracking Flags




(3 attachments)



3 years ago
Created attachment 8518915 [details]

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.


3 years ago
Keywords: crash
tracking-e10s: --- → ?
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]
Keywords: assertion
Summary: [e10s] Crash whilst doing nothing special → [e10s] Assertion failure: mUsedShmems.empty(), at gfx/layers/ipc/ISurfaceAllocator.cpp

Comment 2

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

Nope, this was on a blank profile.


3 years ago
Version: 32 Branch → 36 Branch
tracking-e10s: ? → +
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?
Flags: needinfo?(sotaro.ikeda.g)
Flags: needinfo?(nical.bugzilla)
Flags: needinfo?(mdeboer)

Comment 4

3 years ago
Hasn't happened since and I was running a fresh local build (integration/fx-team) that day.
Flags: needinfo?(mdeboer)
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).
Flags: needinfo?(nical.bugzilla)
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.
Flags: needinfo?(sotaro.ikeda.g)
I'm able to reproduce this pretty easily on e10s on OS X Yosemite with a debug build.

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
Created attachment 8537464 [details]
e10s crash stack
Blocks: 993639
I am also easily able to reproduce this in a debug build on OS X on Mountain Lion using the steps in comment 7.

tracking-e10s: + → ?
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?
Assignee: nobody → mchang
Flags: needinfo?(wmccloskey)
Flags: needinfo?(wmccloskey)
tracking-e10s: ? → +


2 years ago
Duplicate of this bug: 1162536
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.
Created attachment 8609310 [details]
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.
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?
Flags: needinfo?(mchang)
Flags: needinfo?(mchang) → needinfo?(nical.bugzilla)
Mason, no luck with extra instrumentation?
Flags: needinfo?(mchang)
I haven't looked at this in a while. Still waiting on nical to see if we can delete this assertion for now.
Flags: needinfo?(mchang)
(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.
Flags: needinfo?(nical.bugzilla)
(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!
Assignee: mchang → nobody
Flags: needinfo?(mrbkap)


2 years ago
Component: Untriaged → Tracking
Product: Firefox → Core
QA Contact: chofmann


2 years ago
See Also: → bug 1214863
I haven't seen this in a while. It seems like it might have been fixed along the way.
Flags: needinfo?(mrbkap)
Let's reopen if it comes back.
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME


a year ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.