See testcase, which crashes current trunk build after 100ms. It doesn't crash in Firefox3.6.8. I can look for a regression range, if wanted. http://crash-stats.mozilla.com/report/index/9be8a1b7-10fd-49c8-a8fc-0d0432100823 0 xul.dll nsFrameManager::ReResolveStyleContext layout/base/nsFrameManager.cpp:1049 1 xul.dll nsFrameManager::ReResolveStyleContext layout/base/nsFrameManager.cpp:1482 2 xul.dll nsFrameManager::ReResolveStyleContext layout/base/nsFrameManager.cpp:1499 3 xul.dll nsFrameManager::ReResolveStyleContext layout/base/nsFrameManager.cpp:1499 4 xul.dll nsFrameManager::ReResolveStyleContext layout/base/nsFrameManager.cpp:1499 5 xul.dll nsFrameManager::ReResolveStyleContext layout/base/nsFrameManager.cpp:1499 6 xul.dll nsFrameManager::ComputeStyleChangeFor layout/base/nsFrameManager.cpp:1552 7 xul.dll mozilla::css::RestyleTracker::ProcessRestyles layout/base/RestyleTracker.cpp:240 8 xul.dll nsCSSFrameConstructor::ProcessPendingRestyles layout/base/nsCSSFrameConstructor.cpp:11606 9 xul.dll PresShell::FlushPendingNotifications layout/base/nsPresShell.cpp:4781 10 xul.dll nsRefreshDriver::Notify layout/base/nsRefreshDriver.cpp:257

Changed the document to standards mode, and moved the function from setTimeout to onload to fix a race condition.

Is this testcase still crashing? We have a number of bugs with nsFrameManager::ReResolveStyleContext signatures, it's hard to get a clear sight of what belongs where and which bug(s) are relevant.

Still crashes: bp-b0c325da-f776-418c-b3c0-076582111217 with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111216 Firefox/11.0a1 ID:20111216031140

http://en.wikipedia.org/wiki/Poodle crashes latest Nightly, and 9.0.1 bp-c78c2629-87c3-456a-9d02-e4bce2120125 bp-41678854-f7bc-4186-af67-8b2c92120125 bp-99d17033-4d11-420d-8677-7fd482120125

Still crashes m-c debug build on Linux, STR: 1. load test in fresh profile (no problem) 2. zoom in one step (CTRL++) => assertions: ###!!! ASSERTION: frame tree not empty, but caller reported complete status: 'aSubtreeRoot->GetPrevInFlow()', file layout/base/nsLayoutUtils.cpp, line 4773 ###!!! ASSERTION: frame tree not empty, but caller reported complete status: 'aSubtreeRoot->GetPrevInFlow()', file layout/base/nsLayoutUtils.cpp, line 4773 ###!!! ASSERTION: Placeholder relationship should have been torn down already; this might mean we have a stray placeholder in the tree.: '!placeholder || nsLayoutUtils::IsProperAncestorFrame(aDestructRoot, placeholder)', file layout/generic/nsFrame.cpp, line 621 ###!!! ASSERTION: No out of flow frame?: 'child', file layout/generic/nsFrame.cpp, line 2108 3. zoom again => slightly different assertions: ###!!! ASSERTION: Null out-of-flow for placeholder?: 'outOfFlow', file layout/base/../generic/nsPlaceholderFrame.h, line 168 ###!!! ASSERTION: no out-of-flow frame: 'outOfFlowFrame', file layout/base/nsFrameManager.cpp, line 1554 ###!!! ASSERTION: out-of-flow frame not a true descendant: 'outOfFlowFrame != resolvedChild', file layout/base/nsFrameManager.cpp, line 1556 followed by a crash: #1 nsIFrame::GetContent (this=0x0) #2 nsFrameManager::ReResolveStyleContext(... aFrame=0x0 ...) #3 nsFrameManager::ReResolveStyleContext etc per comment 0

Testcase and URL in comment 4 works for me in a local m-c debug build on Linux64, without any assertions, and also works in an ASan build.

Crash test: https://hg.mozilla.org/integration/mozilla-inbound/rev/b3b000428e80

Maybe it / bug 875336 was bug 600100.