Closed
Bug 629912
Opened 13 years ago
Closed 13 years ago
4.0b11pre crash [@ NotificationController::TextEnumerator(nsPtrHashKey<nsIContent>*, void*) ][@ nsINode::GetFlags()]
Categories
(Core :: Disability Access APIs, defect, P1)
Tracking
()
RESOLVED
FIXED
mozilla2.0b11
Tracking | Status | |
---|---|---|
blocking2.0 | --- | betaN+ |
status1.9.2 | --- | unaffected |
People
(Reporter: chofmann, Assigned: surkov)
References
()
Details
(Keywords: crash, regression, topcrash, Whiteboard: [ignore comments 0-29][sg:critical?][hardblocker][has patch])
Crash Data
Attachments
(2 files, 1 obsolete file)
4.82 KB,
patch
|
davidb
:
review+
|
Details | Diff | Splinter Review |
2.90 KB,
patch
|
MarcoZ
:
review+
neil
:
superreview+
|
Details | Diff | Splinter Review |
possible new crash on mozilla-central maybe first appearing in build 2011 01 28 030208 stack looks like https://crash-stats.mozilla.com/report/index/e944c84d-58d8-4d56-bf6f-5c6632110129 Frame Module Signature [Expand] Source 0 xul.dll NotificationController::TextEnumerator accessible/src/base/NotificationController.cpp:601 1 xul.dll NotificationController::QueueEvent accessible/src/base/NotificationController.cpp:139 2 xul.dll nsTArray<nsAutoPtr<nsPropertyTable>,nsTArrayDefaultAllocator>::~nsTArray<nsAutoPtr<nsPropertyTable>,nsTArrayDefaultAllocator> obj-firefox/dist/include/nsTArray.h:373 3 xul.dll PL_DHashTableEnumerate obj-firefox/xpcom/build/pldhash.c:754 4 xul.dll nsTArray_base<nsTArrayInfallibleAllocator>::ShrinkCapacity obj-firefox/dist/include/nsTArray-inl.h:135 5 xul.dll NotificationController::WillRefresh accessible/src/base/NotificationController.cpp:247 6 xul.dll nsTArray<nsAutoPtr<nsPropertyTable>,nsTArrayDefaultAllocator>::~nsTArray<nsAutoPtr<nsPropertyTable>,nsTArrayDefaultAllocator> obj-firefox/dist/include/nsTArray.h:373 7 xul.dll PresShell::FlushPendingNotifications layout/base/nsPresShell.cpp:4924 8 xul.dll NotificationController::CreateTextChangeEventFor accessible/src/base/NotificationController.cpp:574 9 xul.dll nsRefreshDriver::Notify layout/base/nsRefreshDriver.cpp:254 10 user32.dll user32.dll@0x1baf8 11 user32.dll user32.dll@0x1bd31 12 xul.dll xul.dll@0xa3776f 13 nspr4.dll PR_AssertCurrentThreadOwnsLock nsprpub/pr/src/threads/combined/prulock.c:404 14 xul.dll mozilla::TimeDuration::ToSeconds xpcom/ds/TimeStamp.cpp:63 15 nspr4.dll PR_Unlock more reports at: https://crash-stats.mozilla.com/report/list?signature=NotificationController%3A%3ATextEnumerator(nsPtrHashKey<nsIContent>*%2C void*)&version=Firefox%3A4.0b11pre source at the top of the stack appears to have been recently changed. 2011-01-28 16:42 +0800 Alexander Surkov - Bug 625652 - make sure accessible tree is correct when rendered text is changed, r=davidb, sr=roc, a=roc 2011-01-28 13:15 +0800 Alexander Surkov - Bug 629394, part3 - replace do_QueryObject on AsHyperText, r=fer, a=davidb 2011-01-28 12:37 +0800 Alexander Surkov - Bug 606924, part5 - rename GetCachedAccessible, r=fer, a=final+ 2011-01-26 14:35 +0800 Alexander Surkov - Bug 606924, part3 - handing document concept, r=davidb, a=blocking2.0Final+ 2011-01-24 10:58 +0800 Alexander Surkov - Bug 606924, part2 - create initial tree, r=davidb, a=blocking2.0Final+ base Alexander Surkov - Bug 498015 - update accessible tree on content insertion after layout, r=davidb, sr=bz, a=blockingBetaN
Reporter | ||
Comment 1•13 years ago
|
||
rising pretty fast, so this should probably block b11.
blocking1.9.2: --- → ?
Updated•13 years ago
|
blocking1.9.2: ? → ---
blocking2.0: --- → betaN+
Whiteboard: [hardblocker]
Comment 3•13 years ago
|
||
Actually I'm not sure why this is failing yet.
Updated•13 years ago
|
Comment 4•13 years ago
|
||
This stack is interesting: https://crash-stats.mozilla.com/report/index/81503836-b361-4e49-8e9c-eefcd2110129 0 xul.dll NotificationController::TextEnumerator accessible/src/base/NotificationController.cpp:604 1 xul.dll nsCycleCollector::Suspect2 xpcom/base/nsCycleCollector.cpp:2363 2 mozcrt19.dll arena_dalloc_small obj-firefox/memory/jemalloc/crtsrc/jemalloc.c:4158 3 xul.dll NotificationController::QueueEvent accessible/src/base/NotificationController.cpp:139 4 xul.dll nsTArray<nsAutoPtr<nsPropertyTable>,nsTArrayDefaultAllocator>::~nsTArray<nsAutoPtr<nsPropertyTable>,nsTArrayDefaultAllocator> obj-firefox/dist/include/nsTArray.h:373 5 xul.dll PL_DHashTableEnumerate obj-firefox/xpcom/build/pldhash.c:754 6 xul.dll nsTArray_base<nsTArrayInfallibleAllocator>::ShrinkCapacity obj-firefox/dist/include/nsTArray-inl.h:135 7 xul.dll NotificationController::WillRefresh
Comment 5•13 years ago
|
||
So far all the stacks look like they are on amd64 hardware.
Comment 6•13 years ago
|
||
CC'ing dbaron because he's awesome, and also might know something about the stack in comment 4.
Comment 7•13 years ago
|
||
Jonas, how does AbortIfOffMainThreadIfCheckFast work?
Updated•13 years ago
|
Keywords: regression,
testcase-wanted
Comment 8•13 years ago
|
||
Unassigning as I can't own this for the next while ( AFK :( )
Assignee: bolterbugz → nobody
AbortIfOffMainThreadIfCheckFast is used to exit firefox if you try to addref or release a cycle collected object from any thread other than the main thread. I.e. if you're trying to use mainthread-only objects on other threads. So if you're seeing that at the top of a crash stack, then you're having a threading issue of some sort. Unfortunately crash-stats seems to be having some issue right now so can't look at the stacks there. (The "IfCheckFast" part of the name is there since the function is a no-op on platforms where we can't quickly check if we're currently on the main thread.)
Comment 11•13 years ago
|
||
I don't see AbortIfOffMainThreadIfCheckFast anywhere on the stack. The bug here seems rather simple. This comment <http://hg.mozilla.org/mozilla-central/annotate/993b69aa088a/accessible/src/base/NotificationController.cpp#l584> seems to say that the node is guaranteed to be in the document, because if it has been removed, the content removal notification has removed it from the hashtable. But that's clearly not the case at all. In fact, I can't find any code which removes any content node from mTextHash anywhere (it's just cleared at times), so no wonder we crash when we try to get the parent pointer without checking its validity. A wallpaper fix would be to bail out if !textNode->IsInDoc(), but I don't know if that's the right fix here. Maybe we should do what the comment says?
Comment 12•13 years ago
|
||
Many of the crashes are reads from 0xffffffffffffffff or near-null which is not too worrying, but a bunch have intermediate values. A few look clearly exploitable, e.g. bp-8d22f1c9-140a-4f01-af82-40e742110129 . "moderate" because it doesn't look like a reliable vector, but it could be worse. Why is this only amd64? Is there some external accessibility software or driver involved in the crash? The correlations tab says "ERROR: No reports generated on 20110129 for Firefox 4.0b11pre." :-(
Whiteboard: [hardblocker] → [sg:moderate][hardblocker]
Assignee | ||
Comment 13•13 years ago
|
||
(In reply to comment #11) > A wallpaper fix would be to bail out if !textNode->IsInDoc(), but I don't know > if that's the right fix here. Maybe we should do what the comment says? If you're right then we could do - if (!containerNode) { + if (!containerNode || !textNode->IsInDoc()) { but honestly stack is confusing.
Comment 14•13 years ago
|
||
I filed a possible dupe of this in bug 629995. Saw that crasher once in current nightly build. However the top of the stack is different than this bug, so am unsure. Maybe it helps! The crash ID from that bug is: bp-451b86fd-8662-4040-9bd3-776732110130 .
Assignee | ||
Comment 16•13 years ago
|
||
Could it because nsIContent is not addrefed? If so then we could either keep nsCOMPtr instead of nsIContent or remove entries from hash when accessible subtree is shutdown.
Assignee | ||
Comment 17•13 years ago
|
||
this should fix either case (comment #11 or comment #16)
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #508232 -
Flags: review?(bolterbugz)
Summary: 4.0b11pre crash [@ NotificationController::TextEnumerator(nsPtrHashKey<nsIContent>*, void*) ] → 4.0b11pre crash [@ NotificationController::TextEnumerator(nsPtrHashKey<nsIContent>*, void*) ][@ nsINode::GetFlags()]
Comment 18•13 years ago
|
||
Comment on attachment 508232 [details] [diff] [review] patch r=me thanks Alexander.
Attachment #508232 -
Flags: review?(bolterbugz) → review+
Assignee | ||
Comment 19•13 years ago
|
||
updated to trunk (I assume bug 626660 will be checked in after this one).
Attachment #508232 -
Attachment is obsolete: true
Updated•13 years ago
|
Attachment #508241 -
Flags: review+
Would be nice if this could get landed today, this crash (under various signatures) is 4 of the 5 topcrashes on nightlies.
Reporter | ||
Comment 21•13 years ago
|
||
we definitely need this fix before beta 11 gets shipped, and freeze date for that is Tuesday. It would be nice to have a few builds to verify the reductions in crashes. This needs to be changed from "beta N+" to "beta1 1 +"
Updated•13 years ago
|
Whiteboard: [sg:moderate][hardblocker] → [sg:moderate][hardblocker][has patch]
Updated•13 years ago
|
Severity: normal → critical
Priority: -- → P1
Assignee | ||
Comment 22•13 years ago
|
||
landed on 2.0 beta 11 - http://hg.mozilla.org/mozilla-central/rev/46c4c8b31b60
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b11
Assignee | ||
Comment 23•13 years ago
|
||
I can reproduce Marco's crash (bug 629995). xul.dll!nsINode::GetFlags() Line 858 + 0x14 bytes C++ xul.dll!nsINode::HasFlag(unsigned long aFlag) Line 853 + 0x8 bytes C++ xul.dll!nsINode::IsElement() Line 378 C++ > xul.dll!NotificationController::TextEnumerator(nsPtrHashKey<nsIContent> * aEntry, void * aUserArg) Line 883 + 0xb bytes C++ xul.dll!nsTHashtable<nsPtrHashKey<nsIContent> >::s_EnumStub(PLDHashTable * table, PLDHashEntryHdr * entry, unsigned int number, void * arg) Line 420 + 0x12 bytes C++ xul.dll!PL_DHashTableEnumerate(PLDHashTable * table, PLDHashOperator (PLDHashTable *, PLDHashEntryHdr *, unsigned int, void *)* etor, void * arg) Line 754 + 0x19 bytes C xul.dll!nsTHashtable<nsPtrHashKey<nsIContent> >::EnumerateEntries(PLDHashOperator (nsPtrHashKey<nsIContent> *, void *)* enumFunc, void * userArg) Line 241 + 0x12 bytes C++ xul.dll!NotificationController::WillRefresh(mozilla::TimeStamp aTime) Line 249 C++ The text node return bad parent, has not null primary frame that has all null value members (mContent and etc). There's no accessible for this text node. If we weren't in time to create an accessible before text node goes away then the proposed patch doesn't work.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 24•13 years ago
|
||
Attachment #508352 -
Flags: superreview?(neil)
Attachment #508352 -
Flags: review?(bolterbugz)
Assignee | ||
Updated•13 years ago
|
Attachment #508241 -
Attachment description: patch2 → part1v2
Comment 25•13 years ago
|
||
Comment on attachment 508352 [details] [diff] [review] part2v1: keep text nodes addrefed (landed 2011-01-31) >+ template<class T> >+ class nsCOMPtrHashKey : public PLDHashEntryHdr (This class should probably be moved into nsHashKeys.h at some point.) If you had noticed nsISupportsHashKey (which is effectively the same as nsCOMPtrHashKey<nsISupports>) you might not have made these two nits: >+ ~nsCOMPtrHashKey() { mKey = nsnull; } No need to set mKey here, we're about to destroy it anyway. >+ KeyType GetKey() const { return mKey.get(); } No need for the .get() here, the compiler should be able to cast it.
Attachment #508352 -
Flags: superreview?(neil) → superreview+
Comment 26•13 years ago
|
||
Comment on attachment 508352 [details] [diff] [review] part2v1: keep text nodes addrefed (landed 2011-01-31) I'm not davidb, but r=me as per IRC question from Alexander.
Attachment #508352 -
Flags: review?(bolterbugz) → review+
Assignee | ||
Comment 27•13 years ago
|
||
landed with Neil's comments addressed - http://hg.mozilla.org/mozilla-central/rev/732a38102733
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
Flags: in-testsuite?
Depends on: 630187
Reporter | ||
Comment 28•13 years ago
|
||
not seeing any more reports on mozilla-central builds after 2011 01 31 03 03:35
Reporter | ||
Updated•13 years ago
|
Status: RESOLVED → VERIFIED
I'm still hitting this on today's nightly: https://crash-stats.mozilla.com/report/index/3169c78e-1755-45b2-b468-93f282110214 https://crash-stats.mozilla.com/report/index/bp-577e690a-1c0e-431c-9567-0655f2110214 https://crash-stats.mozilla.com/report/index/bp-eff360c3-a5fc-4271-b6ef-448fa2110214
Assignee | ||
Comment 30•13 years ago
|
||
It looks like either mContent of nsTextFrame is dead when a11y is notified from nsTextFrame::TextReflow - http://hg.mozilla.org/mozilla-central/diff/95a9192221ea/layout/generic/nsTextFrameThebes.cpp, either mContent's parent wasn't cleared due to some reason and GetNodeParent() returns dead object (http://hg.mozilla.org/mozilla-central/annotate/26421a3b68f3/accessible/src/base/NotificationController.cpp#l603). Boris, do you have any ideas?
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 31•13 years ago
|
||
(In reply to comment #29) > I'm still hitting this on today's nightly: it's possible that backing out the first part of this patch (CancelTextUpdate stuffs) in bug 631772 triggers this crash (since it was landed yesterday). If we're not able to find actual reason of the bug then we can get back CancelTextUpdate so that it will collect text nodes in additional hash rather than remove them from main hash.
Comment 32•13 years ago
|
||
> It looks like either mContent of nsTextFrame is dead when a11y is notified from > nsTextFrame::TextReflow - That can't happen. Looking at the three stacks from comment 29: 1) Not sure what's going on here. 2) textNode is null (0xc is the offset of mParentPtrBits in nsINode). 3) Not sure. I definitely don't see a way that we could end up with null in that hashtable, barring some sort of memory corruption... Comment 31 is possible; if you're modifying the hashtable during enumeration, then you could easily read garbage memory. Don't do that!
Assignee | ||
Comment 33•13 years ago
|
||
(In reply to comment #32) > Comment 31 is possible; if you're modifying the hashtable during enumeration, > then you could easily read garbage memory. Don't do that! Text nodes aren't removed from hash when hash is iterated because http://hg.mozilla.org/mozilla-central/rev/2e5aced41e8d was landed 11 Feb and Kyle's build is dated by 13 Feb. If the problem is the hash is modified while it's traversed then I could think of only one way. We insert new accessible into a tree when hash is traversed and that somehow triggers nsTextFrame::ReflowText what appends text node into hash. Kyle, do you have reliable steps to reproduce or can you trigger the crash often enough so that you can say if a patch helps or not?
Comment 34•13 years ago
|
||
> Text nodes aren't removed from hash when hash is iterated
OK. In that case, I'm really not sure what's going on here.... I'd hope inserting new accessibles can't trigger reflow; if it can we have serious problems. Can you check on that?
Assignee | ||
Comment 35•13 years ago
|
||
(In reply to comment #34) > > Text nodes aren't removed from hash when hash is iterated > > OK. In that case, I'm really not sure what's going on here.... I'd hope > inserting new accessibles can't trigger reflow; it shouldn't but iirc we had that in the past > if it can we have serious > problems. Can you check on that? I can check if we have flush layout stuffs on the stack (and perhaps remove them at all since it should be ok now). But I don't have ideas what else can trigger reflow. Can you give me a hint what should I look for?
Comment 36•13 years ago
|
||
> it shouldn't but iirc we had that in the past Well, any time that happens seems like an exploitable security issue, offhand, so I'd really hope we make sure it can't happen. > Can you give me a hint what should I look for? 1) Any time you flush. 2) Any time you call code you don't control and that might flush. Examples of #2 would be any DOM API asking for position information, say. Or scrolling. Or anything that spins the event loop, of course. That said, there should be asserts for these sort of things; if we aren't hitting them then chances are we're not doing them. Then again, do we really do much running of debug builds with a11y enabled?
Assignee | ||
Comment 37•13 years ago
|
||
I filed bug 634197 for that.
(In reply to comment #33) > Kyle, do you have reliable steps to reproduce or can you trigger the crash > often enough so that you can say if a patch helps or not? Unfortunately not. I can start running a debug build and see if I'm hitting asserts. Let me know if you want me to try that.
Comment 39•13 years ago
|
||
What are the specific asserts to look for?
Comment 40•13 years ago
|
||
Um.... anything about reentering frame construction or reflow, probably?
Comment 41•13 years ago
|
||
Alexander, the FF4 endgame drivers would like an ETA on this bug. How about a best case, worst case range? (I realize the difficulty, given investigation is continuing and we have no reliable STR)
Comment 42•13 years ago
|
||
David suggests the new crashes might be exploitable. Marking as such.
Group: core-security
Whiteboard: [sg:moderate][hardblocker][has patch] → [sg:critical?][hardblocker][has patch]
Reporter | ||
Comment 43•13 years ago
|
||
it looks like one of the signatures hasn't been seen since jan30 builds, and the other signature has possibly been reduced in volume back down to the residual level. NotificationController::TextEnumerator.nsPtrHashKey.nsIContent..,.void.. date total breakdown by build crashes count build, count build, ... 20110207 3 4.0b11pre2011013103 3 , 20110208 4 2 4.0b11pre2011013003, 1 4.0b11pre2011013103, 1 4.0b11pre2011012803, 20110209 1 4.0b11pre2011012803 1 , 20110210 2 1 4.0b11pre2011013003, 1 4.0b11pre2011012903, 20110211 1 4.0b11pre2011013003 1 , 20110212 1 4.0b11pre2011013003 1 , 20110213 20110214 nsINode::GetFlags.. date total breakdown by build crashes count build, count build, ... 20110212 61 25 3.6.132010120307, 17 4.0b12010063014, 7 4.0b112011020314, 2 3.6.142011020713, 1 4.0b12pre2011021103, 1 4.0b11pre2011013003, 1 4.0b11pre2011012903, 1 4.0b102011012116, 1 4.0b12010062821, 1 3.6.82010072215, 1 3.6.142011012114, 1 3.6.132010112205, 1 3.6.122010102621, 1 3.62010011514, 20110213 48 18 3.6.132010120307, 10 4.0b12010063014, 8 3.5.162010113007, 7 4.0b112011020314, 2 3.6.102010091412, 1 4.0b72010110414, 1 3.6.82010072215, 1 3.6.122010102621, 20110214 56 26 3.6.132010120307, 12 4.0b112011020314, 6 4.0b12010063014, 3 3.5.162010113007, 2 3.7a52010061006, 2 3.0.52008120122, 1 4.0b12pre2011021403, 1 4.0b12010062821, 1 3.6.62010062523, 1 3.6.22010031607, 1 3.6.142011020713,
I'm going to try to catch this in a debug build.
I haven't been able to reproduce a crash, but a11y is definitely being naughty. Example stack:
> xul.dll!NS_DebugBreak_P(unsigned int aSeverity, const char * aStr, const char * aExpr, const char * aFile, int aLine) Line 372 C++
xul.dll!PL_DHashTableOperate(PLDHashTable * table, const void * key, PLDHashOperator op) Line 612 + 0x42 bytes C
xul.dll!nsTHashtable<NotificationController::nsCOMPtrHashKey<nsIContent> >::PutEntry(nsIContent * aKey) Line 188 + 0xd bytes C++
xul.dll!NotificationController::ScheduleTextUpdate(nsIContent * aTextNode) Line 160 + 0x12 bytes C++
xul.dll!nsDocAccessible::UpdateText(nsIContent * aTextNode) Line 320 + 0x12 bytes C++
xul.dll!nsAccessibilityService::UpdateText(nsIPresShell * aPresShell, nsIContent * aContent) Line 538 C++
xul.dll!nsTextFrame::ReflowText(nsLineLayout & aLineLayout, int aAvailableWidth, nsIRenderingContext * aRenderingContext, int aShouldBlink, nsHTMLReflowMetrics & aMetrics, unsigned int & aStatus) Line 6969 C++
xul.dll!nsLineLayout::ReflowFrame(nsIFrame * aFrame, unsigned int & aReflowStatus, nsHTMLReflowMetrics * aMetrics, int & aPushedFrame) Line 864 C++
xul.dll!nsBlockFrame::ReflowInlineFrame(nsBlockReflowState & aState, nsLineLayout & aLineLayout, nsLineList_iterator aLine, nsIFrame * aFrame, LineReflowStatus * aLineReflowStatus) Line 3812 C++
xul.dll!nsBlockFrame::DoReflowInlineFrames(nsBlockReflowState & aState, nsLineLayout & aLineLayout, nsLineList_iterator aLine, nsFlowAreaRect & aFloatAvailableSpace, int & aAvailableSpaceHeight, nsFloatManager::SavedState * aFloatStateBeforeLine, int * aKeepReflowGoing, LineReflowStatus * aLineReflowStatus, int aAllowPullUp) Line 3607 + 0x17 bytes C++
xul.dll!nsBlockFrame::ReflowInlineFrames(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing) Line 3467 C++
xul.dll!nsBlockFrame::ReflowLine(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing) Line 2566 C++
xul.dll!nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & aState) Line 1999 + 0x13 bytes C++
xul.dll!nsBlockFrame::Reflow(nsPresContext * aPresContext, nsHTMLReflowMetrics & aMetrics, const nsHTMLReflowState & aReflowState, unsigned int & aStatus) Line 1081 C++
xul.dll!nsContainerFrame::ReflowChild(nsIFrame * aKidFrame, nsPresContext * aPresContext, nsHTMLReflowMetrics & aDesiredSize, const nsHTMLReflowState & aReflowState, int aX, int aY, unsigned int aFlags, unsigned int & aStatus, nsOverflowContinuationTracker * aTracker) Line 740 + 0x16 bytes C++
xul.dll!nsHTMLScrollFrame::ReflowScrolledFrame(ScrollReflowState * aState, int aAssumeHScroll, int aAssumeVScroll, nsHTMLReflowMetrics * aMetrics, int aFirstPass) Line 535 + 0x2b bytes C++
xul.dll!nsHTMLScrollFrame::ReflowContents(ScrollReflowState * aState, const nsHTMLReflowMetrics & aDesiredSize) Line 686 + 0x2b bytes C++
xul.dll!nsHTMLScrollFrame::Reflow(nsPresContext * aPresContext, nsHTMLReflowMetrics & aDesiredSize, const nsHTMLReflowState & aReflowState, unsigned int & aStatus) Line 868 + 0x3b bytes C++
xul.dll!nsBlockReflowContext::ReflowBlock(const nsRect & aSpace, int aApplyTopMargin, nsCollapsingMargin & aPrevMargin, int aClearance, int aIsAdjacentWithTop, nsLineBox * aLine, nsHTMLReflowState & aFrameRS, unsigned int & aFrameReflowStatus, nsBlockReflowState & aState) Line 297 + 0x2d bytes C++
xul.dll!nsBlockFrame::ReflowFloat(nsBlockReflowState & aState, const nsRect & aAdjustedAvailableSpace, nsIFrame * aFloat, nsMargin & aFloatMargin, int aFloatPushedDown, unsigned int & aReflowStatus) Line 5793 + 0x1f bytes C++
xul.dll!nsBlockReflowState::FlowAndPlaceFloat(nsIFrame * aFloat) Line 825 C++
xul.dll!nsBlockReflowState::AddFloat(nsLineLayout * aLineLayout, nsIFrame * aFloat, int aAvailableWidth) Line 576 + 0x8 bytes C++
xul.dll!nsLineLayout::ReflowFrame(nsIFrame * aFrame, unsigned int & aReflowStatus, nsHTMLReflowMetrics * aMetrics, int & aPushedFrame) Line 899 C++
xul.dll!nsBlockFrame::ReflowInlineFrame(nsBlockReflowState & aState, nsLineLayout & aLineLayout, nsLineList_iterator aLine, nsIFrame * aFrame, LineReflowStatus * aLineReflowStatus) Line 3812 C++
xul.dll!nsBlockFrame::DoReflowInlineFrames(nsBlockReflowState & aState, nsLineLayout & aLineLayout, nsLineList_iterator aLine, nsFlowAreaRect & aFloatAvailableSpace, int & aAvailableSpaceHeight, nsFloatManager::SavedState * aFloatStateBeforeLine, int * aKeepReflowGoing, LineReflowStatus * aLineReflowStatus, int aAllowPullUp) Line 3607 + 0x17 bytes C++
xul.dll!nsBlockFrame::ReflowInlineFrames(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing) Line 3467 C++
xul.dll!nsBlockFrame::ReflowLine(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing) Line 2566 C++
xul.dll!nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & aState) Line 1999 + 0x13 bytes C++
xul.dll!nsBlockFrame::Reflow(nsPresContext * aPresContext, nsHTMLReflowMetrics & aMetrics, const nsHTMLReflowState & aReflowState, unsigned int & aStatus) Line 1081 C++
xul.dll!nsLineLayout::ReflowFrame(nsIFrame * aFrame, unsigned int & aReflowStatus, nsHTMLReflowMetrics * aMetrics, int & aPushedFrame) Line 853 + 0x87 bytes C++
xul.dll!nsBlockFrame::ReflowInlineFrame(nsBlockReflowState & aState, nsLineLayout & aLineLayout, nsLineList_iterator aLine, nsIFrame * aFrame, LineReflowStatus * aLineReflowStatus) Line 3812 C++
xul.dll!nsBlockFrame::DoReflowInlineFrames(nsBlockReflowState & aState, nsLineLayout & aLineLayout, nsLineList_iterator aLine, nsFlowAreaRect & aFloatAvailableSpace, int & aAvailableSpaceHeight, nsFloatManager::SavedState * aFloatStateBeforeLine, int * aKeepReflowGoing, LineReflowStatus * aLineReflowStatus, int aAllowPullUp) Line 3607 + 0x17 bytes C++
xul.dll!nsBlockFrame::ReflowInlineFrames(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing) Line 3467 C++
xul.dll!nsBlockFrame::ReflowLine(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing) Line 2566 C++
xul.dll!nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & aState) Line 1999 + 0x13 bytes C++
xul.dll!nsBlockFrame::Reflow(nsPresContext * aPresContext, nsHTMLReflowMetrics & aMetrics, const nsHTMLReflowState & aReflowState, unsigned int & aStatus) Line 1081 C++
xul.dll!nsBlockReflowContext::ReflowBlock(const nsRect & aSpace, int aApplyTopMargin, nsCollapsingMargin & aPrevMargin, int aClearance, int aIsAdjacentWithTop, nsLineBox * aLine, nsHTMLReflowState & aFrameRS, unsigned int & aFrameReflowStatus, nsBlockReflowState & aState) Line 297 + 0x2d bytes C++
xul.dll!nsBlockFrame::ReflowBlockFrame(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing) Line 3190 C++
xul.dll!nsBlockFrame::ReflowLine(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing) Line 2507 C++
xul.dll!nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & aState) Line 1999 + 0x13 bytes C++
xul.dll!nsBlockFrame::Reflow(nsPresContext * aPresContext, nsHTMLReflowMetrics & aMetrics, const nsHTMLReflowState & aReflowState, unsigned int & aStatus) Line 1081 C++
xul.dll!nsBlockReflowContext::ReflowBlock(const nsRect & aSpace, int aApplyTopMargin, nsCollapsingMargin & aPrevMargin, int aClearance, int aIsAdjacentWithTop, nsLineBox * aLine, nsHTMLReflowState & aFrameRS, unsigned int & aFrameReflowStatus, nsBlockReflowState & aState) Line 297 + 0x2d bytes C++
xul.dll!nsBlockFrame::ReflowBlockFrame(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing) Line 3190 C++
xul.dll!nsBlockFrame::ReflowLine(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing) Line 2507 C++
xul.dll!nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & aState) Line 1999 + 0x13 bytes C++
xul.dll!nsBlockFrame::Reflow(nsPresContext * aPresContext, nsHTMLReflowMetrics & aMetrics, const nsHTMLReflowState & aReflowState, unsigned int & aStatus) Line 1081 C++
xul.dll!nsBlockReflowContext::ReflowBlock(const nsRect & aSpace, int aApplyTopMargin, nsCollapsingMargin & aPrevMargin, int aClearance, int aIsAdjacentWithTop, nsLineBox * aLine, nsHTMLReflowState & aFrameRS, unsigned int & aFrameReflowStatus, nsBlockReflowState & aState) Line 297 + 0x2d bytes C++
xul.dll!nsBlockFrame::ReflowFloat(nsBlockReflowState & aState, const nsRect & aAdjustedAvailableSpace, nsIFrame * aFloat, nsMargin & aFloatMargin, int aFloatPushedDown, unsigned int & aReflowStatus) Line 5793 + 0x1f bytes C++
xul.dll!nsBlockReflowState::FlowAndPlaceFloat(nsIFrame * aFloat) Line 825 C++
xul.dll!nsBlockReflowState::AddFloat(nsLineLayout * aLineLayout, nsIFrame * aFloat, int aAvailableWidth) Line 576 + 0x8 bytes C++
xul.dll!nsLineLayout::ReflowFrame(nsIFrame * aFrame, unsigned int & aReflowStatus, nsHTMLReflowMetrics * aMetrics, int & aPushedFrame) Line 899 C++
xul.dll!nsBlockFrame::ReflowInlineFrame(nsBlockReflowState & aState, nsLineLayout & aLineLayout, nsLineList_iterator aLine, nsIFrame * aFrame, LineReflowStatus * aLineReflowStatus) Line 3812 C++
xul.dll!nsBlockFrame::DoReflowInlineFrames(nsBlockReflowState & aState, nsLineLayout & aLineLayout, nsLineList_iterator aLine, nsFlowAreaRect & aFloatAvailableSpace, int & aAvailableSpaceHeight, nsFloatManager::SavedState * aFloatStateBeforeLine, int * aKeepReflowGoing, LineReflowStatus * aLineReflowStatus, int aAllowPullUp) Line 3607 + 0x17 bytes C++
xul.dll!nsBlockFrame::ReflowInlineFrames(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing) Line 3467 C++
xul.dll!nsBlockFrame::ReflowLine(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing) Line 2566 C++
xul.dll!nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & aState) Line 1999 + 0x13 bytes C++
xul.dll!nsBlockFrame::Reflow(nsPresContext * aPresContext, nsHTMLReflowMetrics & aMetrics, const nsHTMLReflowState & aReflowState, unsigned int & aStatus) Line 1081 C++
xul.dll!nsBlockReflowContext::ReflowBlock(const nsRect & aSpace, int aApplyTopMargin, nsCollapsingMargin & aPrevMargin, int aClearance, int aIsAdjacentWithTop, nsLineBox * aLine, nsHTMLReflowState & aFrameRS, unsigned int & aFrameReflowStatus, nsBlockReflowState & aState) Line 297 + 0x2d bytes C++
xul.dll!nsBlockFrame::ReflowBlockFrame(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing) Line 3190 C++
xul.dll!nsBlockFrame::ReflowLine(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing) Line 2507 C++
xul.dll!nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & aState) Line 1999 + 0x13 bytes C++
xul.dll!nsBlockFrame::Reflow(nsPresContext * aPresContext, nsHTMLReflowMetrics & aMetrics, const nsHTMLReflowState & aReflowState, unsigned int & aStatus) Line 1081 C++
xul.dll!nsBlockReflowContext::ReflowBlock(const nsRect & aSpace, int aApplyTopMargin, nsCollapsingMargin & aPrevMargin, int aClearance, int aIsAdjacentWithTop, nsLineBox * aLine, nsHTMLReflowState & aFrameRS, unsigned int & aFrameReflowStatus, nsBlockReflowState & aState) Line 297 + 0x2d bytes C++
xul.dll!nsBlockFrame::ReflowBlockFrame(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing) Line 3190 C++
xul.dll!nsBlockFrame::ReflowLine(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing) Line 2507 C++
xul.dll!nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & aState) Line 1999 + 0x13 bytes C++
xul.dll!nsBlockFrame::Reflow(nsPresContext * aPresContext, nsHTMLReflowMetrics & aMetrics, const nsHTMLReflowState & aReflowState, unsigned int & aStatus) Line 1081 C++
xul.dll!nsBlockReflowContext::ReflowBlock(const nsRect & aSpace, int aApplyTopMargin, nsCollapsingMargin & aPrevMargin, int aClearance, int aIsAdjacentWithTop, nsLineBox * aLine, nsHTMLReflowState & aFrameRS, unsigned int & aFrameReflowStatus, nsBlockReflowState & aState) Line 297 + 0x2d bytes C++
xul.dll!nsBlockFrame::ReflowBlockFrame(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing) Line 3190 C++
xul.dll!nsBlockFrame::ReflowLine(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing) Line 2507 C++
xul.dll!nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & aState) Line 1999 + 0x13 bytes C++
xul.dll!nsBlockFrame::Reflow(nsPresContext * aPresContext, nsHTMLReflowMetrics & aMetrics, const nsHTMLReflowState & aReflowState, unsigned int & aStatus) Line 1081 C++
xul.dll!nsContainerFrame::ReflowChild(nsIFrame * aKidFrame, nsPresContext * aPresContext, nsHTMLReflowMetrics & aDesiredSize, const nsHTMLReflowState & aReflowState, int aX, int aY, unsigned int aFlags, unsigned int & aStatus, nsOverflowContinuationTracker * aTracker) Line 740 + 0x16 bytes C++
xul.dll!nsCanvasFrame::Reflow(nsPresContext * aPresContext, nsHTMLReflowMetrics & aDesiredSize, const nsHTMLReflowState & aReflowState, unsigned int & aStatus) Line 498 C++
xul.dll!nsContainerFrame::ReflowChild(nsIFrame * aKidFrame, nsPresContext * aPresContext, nsHTMLReflowMetrics & aDesiredSize, const nsHTMLReflowState & aReflowState, int aX, int aY, unsigned int aFlags, unsigned int & aStatus, nsOverflowContinuationTracker * aTracker) Line 740 + 0x16 bytes C++
xul.dll!nsHTMLScrollFrame::ReflowScrolledFrame(ScrollReflowState * aState, int aAssumeHScroll, int aAssumeVScroll, nsHTMLReflowMetrics * aMetrics, int aFirstPass) Line 535 + 0x2b bytes C++
xul.dll!nsHTMLScrollFrame::ReflowContents(ScrollReflowState * aState, const nsHTMLReflowMetrics & aDesiredSize) Line 686 + 0x2b bytes C++
xul.dll!nsHTMLScrollFrame::Reflow(nsPresContext * aPresContext, nsHTMLReflowMetrics & aDesiredSize, const nsHTMLReflowState & aReflowState, unsigned int & aStatus) Line 868 + 0x3b bytes C++
xul.dll!nsContainerFrame::ReflowChild(nsIFrame * aKidFrame, nsPresContext * aPresContext, nsHTMLReflowMetrics & aDesiredSize, const nsHTMLReflowState & aReflowState, int aX, int aY, unsigned int aFlags, unsigned int & aStatus, nsOverflowContinuationTracker * aTracker) Line 740 + 0x16 bytes C++
xul.dll!ViewportFrame::Reflow(nsPresContext * aPresContext, nsHTMLReflowMetrics & aDesiredSize, const nsHTMLReflowState & aReflowState, unsigned int & aStatus) Line 294 C++
xul.dll!PresShell::DoReflow(nsIFrame * target, int aInterruptible) Line 7873 C++
xul.dll!PresShell::ProcessReflowCommands(int aInterruptible) Line 8002 + 0xc bytes C++
xul.dll!PresShell::FlushPendingNotifications(mozFlushType aType) Line 4901 + 0x11 bytes C++
xul.dll!nsAccessible::GetState(unsigned int * aState, unsigned int * aExtraState) Line 1534 C++
xul.dll!nsAccUtils::State(nsIAccessible * aAcc) Line 307 C++
xul.dll!nsLinkableAccessible::BindToParent(nsAccessible * aParent, unsigned int aIndexInParent) Line 265 + 0x1a bytes C++
xul.dll!nsAccessible::AppendChild(nsAccessible * aChild) Line 2778 C++
xul.dll!nsAccessible::CacheChildren() Line 3146 + 0x2c bytes C++
xul.dll!nsAccessible::EnsureChildren() Line 3194 C++
xul.dll!nsDocAccessible::ProcessContentInserted(nsAccessible * aContainer, const nsTArray<nsCOMPtr<nsIContent>,nsTArrayDefaultAllocator> * aInsertedContent) Line 1773 C++
xul.dll!NotificationController::TextEnumerator(NotificationController::nsCOMPtrHashKey<nsIContent> * aEntry, void * aUserArg) Line 676 C++
xul.dll!nsTHashtable<NotificationController::nsCOMPtrHashKey<nsIContent> >::s_EnumStub(PLDHashTable * table, PLDHashEntryHdr * entry, unsigned int number, void * arg) Line 420 + 0xd bytes C++
xul.dll!PL_DHashTableEnumerate(PLDHashTable * table, PLDHashOperator (PLDHashTable *, PLDHashEntryHdr *, unsigned int, void *)* etor, void * arg) Line 754 + 0xb bytes C
xul.dll!nsTHashtable<NotificationController::nsCOMPtrHashKey<nsIContent> >::EnumerateEntries(PLDHashOperator (NotificationController::nsCOMPtrHashKey<nsIContent> *, void *)* enumFunc, void * userArg) Line 241 + 0xf bytes C++
xul.dll!NotificationController::WillRefresh(mozilla::TimeStamp aTime) Line 250 C++
xul.dll!nsRefreshDriver::Notify(nsITimer * __formal) Line 256 C++
xul.dll!nsTimerImpl::Fire() Line 441 C++
xul.dll!nsTimerEvent::Run() Line 519 C++
xul.dll!nsThread::ProcessNextEvent(int mayWait, int * result) Line 633 + 0xe bytes C++
xul.dll!NS_ProcessNextEvent_P(nsIThread * thread, int mayWait) Line 250 + 0xd bytes C++
xul.dll!mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate * aDelegate) Line 110 + 0xa bytes C++
xul.dll!MessageLoop::RunInternal() Line 219 + 0x9 bytes C++
xul.dll!MessageLoop::RunHandler() Line 203 C++
xul.dll!MessageLoop::Run() Line 177 C++
xul.dll!nsBaseAppShell::Run() Line 198 C++
xul.dll!nsAppShell::Run() Line 270 C++
xul.dll!nsAppStartup::Run() Line 221 C++
xul.dll!XRE_main(int argc, char * * argv, const nsXREAppData * aAppData) Line 3769 C++
firefox.exe!NS_internal_main(int argc, char * * argv) Line 159 C++
firefox.exe!wmain(int argc, wchar_t * * argv) Line 130 C++
firefox.exe!__tmainCRTStartup() Line 552 + 0x19 bytes C
firefox.exe!wmainCRTStartup() Line 371 C
kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes
ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes
ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes
I kinda wonder if *anyone* runs a11y in a debug build; it breaks some assertion on pretty much every navigation ....
Comment 47•13 years ago
|
||
AHA! Yes, the stack in comment 46 is showing the hashtable being modified while being enumerated. The relevant part of that stack: PresShell::FlushPendingNotifications(mozFlushType aType) Line 4901 + 0x11 bytes C++ nsAccessible::GetState(unsigned int * aState, unsigned int * aExtraState) Line 1534 C++ nsAccUtils::State(nsIAccessible * aAcc) Line 307 C++ nsLinkableAccessible::BindToParent(nsAccessible * aParent, unsigned int aIndexInParent) Line 265 + 0x1a bytes C++ nsAccessible::AppendChild(nsAccessible * aChild) Line 2778 C++ nsAccessible::CacheChildren() Line 3146 + 0x2c bytes C++ nsAccessible::EnsureChildren() Line 3194 C++ nsDocAccessible::ProcessContentInserted(nsAccessible * aContainer, const nsTArray<nsCOMPtr<nsIContent>,nsTArrayDefaultAllocator> * aInsertedContent) Line 1773 C++ NotificationController::TextEnumerator(NotificationController::nsCOMPtrHashKey<nsIContent> * aEntry, void * aUserArg) Line 676 C++ You need to stop doing that. Or copy the hashtable before processing it.
Comment 48•13 years ago
|
||
Oh, and to be clear the rest of the stack is just reflow and then we reflow some textframe and it adds to the hashtable, and lossage proceeds.
I can reproduce the stack above by loading www.dailykos.com and switching focus from and back to the browser while the page is loading.
(In reply to comment #49) > I can reproduce the stack above by loading www.dailykos.com and switching focus > from and back to the browser while the page is loading. Well, sort of reproduce. It normally takes a few tries. Let me know if I can help test patches for this or provide more information.
Assignee | ||
Comment 51•13 years ago
|
||
Ok, the fix is we should remove flush layout calls from GetStates (also it makes sense to remove it from GetBounds to be on safe side). It appears we don't need it anymore. Boris, we're allowed to get frame size (and able to get correct result) when refresh driver notifies us, right?
Comment 52•13 years ago
|
||
> Boris, we're allowed to get frame size (and able to get
> correct result) when refresh driver notifies us, right?
You're a Display refresh observer, right? If so, you'll be called after reflow is "done". Whether you get "correct" results will depend on whether it was interrupted or not....
Assignee | ||
Comment 53•13 years ago
|
||
(In reply to comment #52) > > Boris, we're allowed to get frame size (and able to get > > correct result) when refresh driver notifies us, right? > > You're a Display refresh observer, right? correct > If so, you'll be called after reflow > is "done". Whether you get "correct" results will depend on whether it was > interrupted or not.... if I do layout flush then am I guaranteed it wont be interrupted ana processed sync?
Assignee | ||
Comment 54•13 years ago
|
||
(In reply to comment #51) > Ok, the fix is we should remove flush layout calls from GetStates (also it > makes sense to remove it from GetBounds to be on safe side). try server build will be here - http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/surkov.alexander@gmail.com-c90e3b156dc4
Assignee | ||
Comment 55•13 years ago
|
||
correct build - http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/surkov.alexander@gmail.com-1bc1bc6b55b0
Comment 56•13 years ago
|
||
Anything in particular I should be looking out for? Any particular test scenarios? I'm running the release build with a screen reader right now, testing different web apps and so far don't see anything wrong.
Comment 57•13 years ago
|
||
I'm getting a side by side error trying to run the debug try builds.
You need the 2005 debug CRT (which means you need the compiler installed) to run windows debug builds from try. Personally I find it easier to just compile my own :-)
Comment 59•13 years ago
|
||
Ugh yeah I'm not installing an older compiler. Kyle are you picking up any asserts with the the try build?
Won't be able to test until this evening.
Comment 61•13 years ago
|
||
If you can give me a STR, I can test it (I have a debug build with a11y built in).
Comment 62•13 years ago
|
||
(In reply to comment #61) > If you can give me a STR, I can test it (I have a debug build with a11y built > in). Comment 49 is the closest we have.
Comment 63•13 years ago
|
||
I'm also testing a local debug build FWIW.
Comment 64•13 years ago
|
||
> if I do layout flush then am I guaranteed it wont be interrupted
Yes, though you should clearly try to not flush if at all possible, since that will simply make interruptible reflow useless (while still paying the performance penalty for it).
Comment 65•13 years ago
|
||
The latest try build removes our only two flush calls. A local debug build that does the same is running pretty clean for me (yeah we still have some assertion noise to clean up but I don't think I'm seeing the bad assertions). Would still be good to hear back from Kyle (later).
Comment 66•13 years ago
|
||
David thinks the second part of this bug doesn't need to hard block, at which point it should be split out into its own follow up and this one closed out.
Whiteboard: [sg:critical?][hardblocker][has patch] → [sg:critical?][hardblocker]
Comment 67•13 years ago
|
||
I can't reproduce using comment 49.
Comment 68•13 years ago
|
||
Follow up to the endgame driver team: Note the currently attached patches 'part1v2' and 'part2v1' already landed and mostly fixed things for the first incantation of this bug. Based on low crash numbers (comment 43) I'm not sure if the resurrected version (born via comment 29) of this bug would hardblock, except that Kyle's stack in comment 45 is worries me. So I'd keep hardblocking status as we need to sort this out but I don't think we absolutely need betaN+ if we're just looking to remove our flush calls.
Whiteboard: [sg:critical?][hardblocker] → [ignore comments 0-29][sg:critical?][hardblocker][has patch]
Comment 69•13 years ago
|
||
Alexander, just in case I'm sleeping when you ask for review. r+ for http://hg.mozilla.org/try/rev/1bc1bc6b55b0
Updated•13 years ago
|
Attachment #508241 -
Attachment description: part1v2 → part1v2 (landed 2011-01-30)
Updated•13 years ago
|
Attachment #508352 -
Attachment description: part2v1: keep text nodes addrefed → part2v1: keep text nodes addrefed (landed 2011-01-31)
Comment 70•13 years ago
|
||
So are we saying this should this be changed to Final+?
I was unable to reproduce the hashtable recursion assertions after 30 minutes of banging on the browser with surkov's patch.
Assignee | ||
Comment 72•13 years ago
|
||
part3 landed - http://hg.mozilla.org/mozilla-central/rev/6de5f3245650
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
Updated•13 years ago
|
Crash Signature: [@ NotificationController::TextEnumerator(nsPtrHashKey<nsIContent>*, void*) ]
[@ nsINode::GetFlags()]
Updated•13 years ago
|
Group: core-security
Crash Signature: [@ NotificationController::TextEnumerator(nsPtrHashKey<nsIContent>*, void*) ]
[@ nsINode::GetFlags()] → [@ NotificationController::TextEnumerator(nsPtrHashKey<nsIContent>*, void*) ]
[@ nsINode::GetFlags()]
Updated•13 years ago
|
status1.9.2:
--- → unaffected
Updated•9 years ago
|
Keywords: testcase-wanted
You need to log in
before you can comment on or make changes to this bug.
Description
•