Closed Bug 793065 Opened 8 years ago Closed 8 years ago
Debug Crash [@ ns
Root Pres Context::Get DOMGeneration() ] | Assertion failure: !m Layer Manager || !m Layer Manager->Is In Transaction()
1. http://fritzo.org/keys/#style=piano 2. Crash Windows XP/7 or Assertion failure: !mLayerManager || !mLayerManager->IsInTransaction() Breakpad's exploitable rates this as medium. Note: eax = 0xdddddddd ecx = 0xdddddddd Operating system: Windows NT 6.1.7601 Service Pack 1 CPU: x86 GenuineIntel family 6 model 37 stepping 1 1 CPU Crash reason: EXCEPTION_ACCESS_VIOLATION_READ Crash address: 0xffffffffdddde065 Thread 0 (crashed) 0 xul.dll!nsRootPresContext::GetDOMGeneration() [nsPresContext.h : 1285 + 0xa] eip = 0x668345ca esp = 0x002abde0 ebp = 0x002abde4 ebx = 0x002ac400 esi = 0x002acd04 edi = 0x002acb74 eax = 0xdddddddd ecx = 0xdddddddd edx = 0x00000000 efl = 0x00210286 Found by: given as instruction pointer in context 1 xul.dll!mozilla::FrameLayerBuilder::CheckDOMModified() [FrameLayerBuilder.cpp : 3044 + 0x13] eip = 0x6683d4db esp = 0x002abdec ebp = 0x002abdf0 Found by: call frame info 2 xul.dll!mozilla::FrameLayerBuilder::DrawThebesLayer(mozilla::layers::ThebesLayer *,gfxContext *,nsIntRegion const &,nsIntRegion const &,void *) [FrameLayerBuilder.cpp : 3023 + 0xa] eip = 0x6683ca7a esp = 0x002abdf8 ebp = 0x002ac040 Found by: call frame info 3 xul.dll!mozilla::layers::BasicThebesLayer::PaintBuffer(gfxContext *,nsIntRegion const &,nsIntRegion const &,nsIntRegion const &,bool,void (*)(mozilla::layers::ThebesLayer *,gfxContext *,nsIntRegion const &,nsIntRegion const &,void *),void *) [BasicThebesLayer.h : 93 + 0x16] eip = 0x67ee55f7 esp = 0x002ac048 ebp = 0x002ac090 Found by: call frame info Found regression between 20120910004817-20120910183953 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1cb30394aa56&tochange=96287ad60bef http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/09/2012-09-10-mozilla-central-debug/firefox-18.0a1.en-US.debug-win32.installer.exe http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/09/2012-09-11-mozilla-central-debug/firefox-18.0a1.en-US.debug-win32.installer.exe A related crash is also found at http://dl.dropbox.com/u/19078872/RTS%20Example%20using%20Astar/index.html. Both this url and the original have prompts for offline storage. In one instance I saw a Assertion failure: !mLayerManager || !mLayerManager->IsInTransaction(), at c:/work/mozilla/builds/nightly/mozilla/widget/windows/nsWindow.cpp:3256 The assertion is much more common on urls such as: http://www.staggeringbeauty.com/ http://ie.microsoft.com/testdrive/Performance/Preschool/Default.html http://chrome.angrybirds.com/ This has the same regression range as the crash.
A full stack would be nice. I'm not familiar with this code at all, but it is somewhat scary to have raw pointer to nsRootPresContext
8 years ago
Mats can you take this one or find an owner?
Assignee: nobody → matspal
I can't reproduce the crash (or assertion) using Win7 and Linux64 debug builds with any of the provided URLs. (ie.microsoft.com didn't load for me though) The assertion was added in bug 781679 to help detect bugs like bug 773097 so this might be something similar.
Assignee: matspal → nobody
Component: Layout → Graphics: Layers
I was able to reproduce the assertion on win7 32bit and 64bit with 32bit nightly debug builds but not rhel6 32bit with 32bit builds or rhel6 64bit with 64bit builds by loading the url from the command line. The assertion was reproducible several times but after a few times I was not able to reproduce it by loading from the command line. However, on Win7 I was able to continue to reproduce it 100% reliably by using the Spider extension to load the url. I was not able to reproduce it using Spider on rhel6 even after 30 attempts however. I haven't tested win7 with 64bit builds. To reproduce with Spider on Win7: 1. Install Spider http://bclary.com/projects/spider/spider/spider.xpi 2. firefox -spider -start -quit -url 'http://fritzo.org/keys/#style=piano'
(In reply to Bob Clary [:bc:] from comment #3) > Created attachment 663395 [details] > assertion crash report This may not be related to the GetDOMGeneration issue. I think this is basically an Azure version of bug 773097 (and see bug 787623). In GetCanvasLayer, we shouldn't call EnsureTarget(). If there's no mTarget, then there's nothing to render and we can just return null (but we have to make sure we MarkContextClean). KFT, can you file a bug for that and fix it? :-)
FrameLayerBuilder::mRootPresContext should be a strong pointer, for sure.
It's difficult to tell what the real problem is, but it's possible that a plugin could be calling back into the browser to run script while we're painting it --- the kind of problem that GetDOMGeneration is guarding against --- and that script destroying mRootPresContext. It's simple and safe to keep mRootPresContext alive for the duration of the FrameLayerBuilder. This will give GetDOMGeneration a chance to work and bail us out of painting without crashing.
Assignee: nobody → roc
Attachment #668304 - Flags: review?
I just retested the 7 urls where I had seen the crash at nsRootPresContext::GetDOMGeneration() and only reproduced the assertion on Windows and not the nsRootPresContext::GetDOMGeneration() crash. In one case on Beta I got a crash but the minidump couldn't be parsed so I don't know what that was about. I think i would be helpful to get the fix for the assertion landed so I can retest without the wallpaper-ish fix to see if the crash can be reproduced.
I guessing Robert meant to cc Karl in comment 7 so doing that now.
Sorry, KFT == Anthony Jones
8 years ago
Attachment #668304 - Flags: review? → review?(matt.woodrow)
Comment 0 says this is a regression from Sept. 10, so marking flags appropriately.
Though it sounds like it may make sense to backport this everywhere.
Attachment #668304 - Flags: review?(matt.woodrow) → review+
Filed bug 798990 with a patch for the assertion issue.
Confirmed crash on 2012-9-20, nightly Verified fixed on build 2012-11-19, 18.0a2 Aurora Verified fixed on build 2012-11-19, nightly
You need to log in before you can comment on or make changes to this bug.