Created attachment 8518915 [details] 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.
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]
(In reply to Chris Peterson (:cpeterson) from comment #1) > Mike: do you have any add-ons installed? Nope, this was on a blank profile.
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?
Hasn't happened since and I was running a fresh local build (integration/fx-team) that day.
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).
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.
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
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.
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?
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?
Mason, no luck with extra instrumentation?
I haven't looked at this in a while. Still waiting on nical to see if we can delete this assertion for now.
(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.
(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!
I haven't seen this in a while. It seems like it might have been fixed along the way.
Let's reopen if it comes back.