Closed Bug 793065 Opened 8 years ago Closed 8 years ago

Debug Crash [@ nsRootPresContext::GetDOMGeneration() ] | Assertion failure: !mLayerManager || !mLayerManager->IsInTransaction()


(Core :: Graphics: Layers, defect)

Windows XP
Not set



Tracking Status
firefox17 --- unaffected
firefox18 + verified
firefox-esr10 --- unaffected
firefox-esr17 --- unaffected


(Reporter: bc, Assigned: roc)




(Keywords: crash, regression, sec-critical, Whiteboard: [adv-main18-])


(3 files)

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 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

A related crash is also found at 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:

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
Attached file assertion crash report
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.  ( 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
2.  firefox -spider -start -quit -url ''
(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
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.
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
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
Whiteboard: [adv-main17-]
Whiteboard: [adv-main17-] → [adv-main18-]
Group: core-security
You need to log in before you can comment on or make changes to this bug.