Seen while reviewing crash stats. Crashes started showing up using the 2011011200 build. http://tinyurl.com/4golztg to the reports which are all Windows. Possible pushlog regression: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4413ed6ba5a5&tochange=c0e05d518f57 Not sure if this belongs in layout? Frame Module Signature [Expand] Source 0 mozcrt19.dll arena_dalloc obj-firefox/memory/jemalloc/crtsrc/jemalloc.c:4275 1 mozcrt19.dll free obj-firefox/memory/jemalloc/crtsrc/jemalloc.c:6121 2 xul.dll nsDisplayListBuilder::LeavePresShell 3 @0x50 4 xul.dll xpc::ResolveNativeProperty js/src/xpconnect/wrappers/XrayWrapper.cpp:296 5 mozjs.dll js::JSProxy::call js/src/jsproxy.cpp:810 6 mozcrt19.dll arena_dalloc_small obj-firefox/memory/jemalloc/crtsrc/jemalloc.c:4153 7 mozcrt19.dll _getptd_noexit obj-firefox/memory/jemalloc/crtsrc/tidtable.c:631 8 mozcrt19.dll _getptd obj-firefox/memory/jemalloc/crtsrc/tidtable.c:656 9 mozcrt19.dll _LocaleUpdate::_LocaleUpdate obj-firefox/memory/jemalloc/crtsrc/setlocal.h:264 10 mozcrt19.dll _input_l obj-firefox/memory/jemalloc/crtsrc/input.c:1086 11 mozcrt19.dll vscan_fn obj-firefox/memory/jemalloc/crtsrc/sscanf.c:66 12 mozcrt19.dll sscanf obj-firefox/memory/jemalloc/crtsrc/sscanf.c:159 13 xul.dll PresShell::Paint layout/base/nsPresShell.cpp:6112 14 xul.dll mozilla::widget::GfxInfo::GetFeatureStatusImpl 15 @0xa4012a3 16 xul.dll nsViewManager::Refresh view/src/nsViewManager.cpp:413 17 xul.dll nsViewManager::DispatchEvent view/src/nsViewManager.cpp:912
heres what apple reported of this similar bug
It is #1 top crasher in today's build.
blocking2.0: --- → ?
Component: jemalloc → Graphics
QA Contact: jemalloc → thebes
Summary: Firefox 4.0b10pre crash [@ arena_dalloc | free | nsDisplayListBuilder::LeavePresShell(nsIFrame*, nsRect const&) ] → Firefox 4.0b10pre crash [@ arena_dalloc | free | nsDisplayListBuilder::LeavePresShell(nsIFrame*, nsRect const&) ][@ RtlEnterCriticalSection ]
We need to find a smaller regression window, a whole lot of stuff landed which could be responsible. Needs to block beta10. STR: load http://www.minecraftwiki.net/wiki/MCLawl/Commands . Scrolling down the page may be required.
###!!! ASSERTION: Want to fire mutation events, but it's not safe: '(aNode->IsNodeOfType(nsINode::eCONTENT) && static_cast<nsIContent*>(aNode)-> IsInNativeAnonymousSubtree()) || sScriptBlockerCount == sRemovableScriptBlockerCount', file c:/builds/mozilla-central/ff-debug/content/base/src/../../../../src/content/base/src/nsContentUtils.cpp, line 3625
Assignee: nobody → mstange
Component: Graphics → Layout
QA Contact: thebes → layout
I really think this needs to be a hardblocker in that "back out bug 621762 if we can't fix it in 24 hours" kind of way.
Whiteboard: [softblocker] → [hardblocker]
OS: Windows XP → All
Hardware: x86 → All
I'm nearly 100% sure the problem is that we're using an nsAutoTArray<ThemeGeometry> inside an nsAutoTArray<PresShellState>. nsAutoTArrays break if you move them around in memory.
Almost anyone could review this really.
Assignee: mstange → roc
Attachment #503722 - Flags: review?(mstange)
Comment on attachment 503722 [details] [diff] [review] fix First come, first served!
Given that we only need this on the top level presshell state, why don't we move this to nsLayoutUtils::PaintFrame and put the theme geometry items on the display list builder?
(In reply to comment #8) > I'm nearly 100% sure the problem is that we're using an > nsAutoTArray<ThemeGeometry> inside an nsAutoTArray<PresShellState>. > nsAutoTArrays break if you move them around in memory. This sounds like something that needs a static or dynamic check to keep people from shooting themselves in the foot.
This does that. It builds, but I haven't tested it on Mac yet.
Attachment #503732 - Flags: review?(tnikkel)
Comment on attachment 503732 [details] [diff] [review] Alternative fix Awesome, thanks.
Attachment #503732 - Flags: review?(tnikkel) → review+
(In reply to comment #12) > This sounds like something that needs a static or dynamic check to keep people > from shooting themselves in the foot. Agreed, feel free to file a followup.
(In reply to comment #15) > (In reply to comment #12) > > This sounds like something that needs a static or dynamic check to keep people > > from shooting themselves in the foot. > > Agreed, feel free to file a followup. Bug 625648.
(In reply to comment #13) > Created attachment 503732 [details] [diff] [review] > Alternative fix > > This does that. It builds, but I haven't tested it on Mac yet. Works great, thanks!
Whiteboard: [hardblocker] → [hardblocker][needs landing]
are the stacks seen in bug 625753 related?
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [hardblocker][needs landing] → [hardblocker]
Duplicate of this bug: 625723
Looks like this is still showing up on crash-stats with the 18th build.
Can you provide a link to some reports?
Thanks, I'm not a frequent users of crash stats.
The frequency has dropped enormously though.
All of the 1/18 crashes are from TM nightlies, which probably haven't merged this fix over.
Crash Signature: [@ arena_dalloc | free | nsDisplayListBuilder::LeavePresShell(nsIFrame*, nsRect const&) ] [@ RtlEnterCriticalSection ]
You need to log in before you can comment on or make changes to this bug.