This bug was filed from the Socorro interface and is report bp-1fdcaa54-94cd-483a-9461-9af340181123. ============================================================= Top 10 frames of crashing thread: 0 xul.dll NS_ABORT_OOM xpcom/base/nsDebugImpl.cpp:628 1 xul.dll nsIFrame::MarkNeedsDisplayItemRebuild layout/generic/nsFrame.cpp:1048 2 xul.dll nsIFrame::SetSize layout/generic/nsIFrame.h:1074 3 xul.dll void nsBlockFrame::ReflowBlockFrame layout/generic/nsBlockFrame.cpp:3716 4 xul.dll void nsBlockFrame::ReflowDirtyLines layout/generic/nsBlockFrame.cpp:2460 5 xul.dll nsBlockFrame::Reflow layout/generic/nsBlockFrame.cpp:1294 6 xul.dll void nsBlockReflowContext::ReflowBlock layout/generic/nsBlockReflowContext.cpp:309 7 xul.dll void nsBlockFrame::ReflowBlockFrame layout/generic/nsBlockFrame.cpp:3573 8 xul.dll void nsBlockFrame::ReflowDirtyLines layout/generic/nsBlockFrame.cpp:2460 9 xul.dll nsBlockFrame::Reflow layout/generic/nsBlockFrame.cpp:1294 ============================================================= this oom signature is newly showing up from installations on windows in firefox 64. could this be related to the work in

The changes for bug 1488599 removed the check for modified frames count, which might have caused this. I am looking into this.

Depends on D13279

Pushed by mikokm@gmail.com: https://hg.mozilla.org/integration/autoland/rev/6a516d21eae6 Part 1: Do not mark frames modified after the rebuild limit has been reached r=mattwoodrow https://hg.mozilla.org/integration/autoland/rev/57816e067da5 Part 2: Do not call MarkNeedsDisplayItemRebuild(), when GetDependentFrame() == Frame() r=mattwoodrow

https://hg.mozilla.org/mozilla-central/rev/6a516d21eae6 https://hg.mozilla.org/mozilla-central/rev/57816e067da5

No crashes on Beta65 so far.

Crash volume on 64 release doesn't seem too worrying so far, I'll call this wontfix.