Closed Bug 42250 Opened 24 years ago Closed 24 years ago

Crash when collapsing mail accounts...

Categories

(Core :: XUL, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: mscott, Assigned: mikepinkerton)

References

Details

(Keywords: crash, Whiteboard: [nsbeta2+][dogfood-])

I've been getting bit by this for a couple weeks now. It doesn't happen all the
time but it does happen about 40% of the time I attempt to collapse a mail
account that has a lot of folders.

I crash in nsMenuPopupFrame::GetNearestEnclosingView because aStartFrame is a
bogus pointer.

Here's the whole stack trace:

nsMenuPopupFrame::GetNearestEnclosingView(nsIPresContext * 0x02fd01c0, nsIFrame
* 0x03e958d4, nsIView * * 0x0012c3a8) line 226
nsMenuPopupFrame::SyncViewWithFrame(nsIPresContext * 0x02fd01c0, const nsString
& {"bottomleft"}, const nsString & {"topleft"}, nsIFrame * 0x03e958d4, int 4,
int 286) line 493 + 20 bytes
nsPopupSetFrame::RePositionPopup(nsBoxLayoutState & {...}) line 348
nsPopupSetFrame::Layout(nsPopupSetFrame * const 0x0372ab9c, nsBoxLayoutState &
{...}) line 235
nsSprocketLayout::Layout(nsSprocketLayout * const 0x014f4720, nsIBox *
0x03729f78, nsBoxLayoutState & {...}) line 407
nsContainerBox::Layout(nsContainerBox * const 0x03729f78, nsBoxLayoutState &
{...}) line 552 + 34 bytes
nsBoxFrame::Layout(nsBoxFrame * const 0x03729f78, nsBoxLayoutState & {...}) line
797 + 13 bytes
nsStackLayout::Layout(nsStackLayout * const 0x014f46e0, nsIBox * 0x03729eec,
nsBoxLayoutState & {...}) line 245
nsContainerBox::Layout(nsContainerBox * const 0x03729eec, nsBoxLayoutState &
{...}) line 552 + 34 bytes
nsBoxFrame::Layout(nsBoxFrame * const 0x03729eec, nsBoxLayoutState & {...}) line
797 + 13 bytes
nsBoxFrame::Reflow(nsBoxFrame * const 0x03729eb4, nsIPresContext * 0x02fd01c0,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 651
nsRootBoxFrame::Reflow(nsRootBoxFrame * const 0x03729eb4, nsIPresContext *
0x02fd01c0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0) line 211
nsContainerFrame::ReflowChild(nsIFrame * 0x03729eb4, nsIPresContext *
0x02fd01c0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0,
int 0, unsigned int 0, unsigned int & 0) line 693 + 31 bytes
ViewportFrame::Reflow(ViewportFrame * const 0x03729e78, nsIPresContext *
0x02fd01c0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0) line 546
nsHTMLReflowCommand::Dispatch(nsHTMLReflowCommand * const 0x03be8b10,
nsIPresContext * 0x02fd01c0, nsHTMLReflowMetrics & {...}, const nsSize & {width=
18030 height=13425}, nsIRenderingContext & {...}) line 145
PresShell::ProcessReflowCommands(int 0) line 3797
PresShell::FlushPendingNotifications(PresShell * const 0x03037530) line 2938
nsTreeRowGroupFrame::OnContentAdded(nsIPresContext * 0x02fd01c0) line 1491
nsTreeRowGroupFrame::OnContentInserted(nsIPresContext * 0x02fd01c0, nsIFrame *
0x03eb21a8, int 2) line 1538
nsCSSFrameConstructor::ContentInserted(nsCSSFrameConstructor * const 0x030378a0,
nsIPresContext * 0x02fd01c0, nsIContent * 0x03ccc040, nsIContent * 0x03ccf0e0,
int 2, nsILayoutHistoryState * 0x03af0040) line 8395
nsCSSFrameConstructor::RecreateFramesForContent(nsIPresContext * 0x02fd01c0,
nsIContent * 0x03ccf0e0) line 10878 + 40 bytes
nsCSSFrameConstructor::AttributeChanged(nsCSSFrameConstructor * const
0x030378a0, nsIPresContext * 0x02fd01c0, nsIContent * 0x03ccf0e0, int 0, nsIAtom
* 0x01536bf0 {"open"}, int 5) line 9837 + 16 bytes
StyleSetImpl::AttributeChanged(StyleSetImpl * const 0x03037960, nsIPresContext *
0x02fd01c0, nsIContent * 0x03ccf0e0, int 0, nsIAtom * 0x01536bf0 {"open"}, int -
1) line 1138
PresShell::AttributeChanged(PresShell * const 0x03037538, nsIDocument *
0x02fd43e0, nsIContent * 0x03ccf0e0, int 0, nsIAtom * 0x01536bf0 {"open"}, int -
1) line 3009 + 57 bytes
nsXULDocument::AttributeChanged(nsXULDocument * const 0x02fd43e0, nsIContent *
0x03ccf0e0, int 0, nsIAtom * 0x01536bf0 {"open"}, int -1) line 1669
nsXULElement::UnsetAttribute(nsXULElement * const 0x03ccf0e0, int 0, nsIAtom *
0x01536bf0 {"open"}, int 1) line 3112
nsXULElement::RemoveAttribute(nsXULElement * const 0x03ccf0ec, const nsString &
{"open"}) line 1354 + 31 bytes
ElementRemoveAttribute(JSContext * 0x02fd2400, JSObject * 0x03749bc0, unsigned
int 1, long * 0x040bcf98, long * 0x0012da48) line 280 + 19 bytes
js_Invoke(JSContext * 0x02fd2400, unsigned int 1, unsigned int 0) line 686 + 23
bytes
js_Interpret(JSContext * 0x02fd2400, long * 0x0012e384) line 2490 + 15 bytes
js_Invoke(JSContext * 0x02fd2400, unsigned int 1, unsigned int 2) line 702 + 13
bytes
js_InternalInvoke(JSContext * 0x02fd2400, JSObject * 0x03ec7718, long 65835832,
unsigned int 0, unsigned int 1, long * 0x0012e51c, long * 0x0012e4bc) line 775 +
19 bytes
JS_CallFunctionValue(JSContext * 0x02fd2400, JSObject * 0x03ec7718, long
65835832, unsigned int 1, long * 0x0012e51c, long * 0x0012e4bc) line 2801 + 31 bytes
nsJSContext::CallEventHandler(nsJSContext * const 0x02fd2070, void * 0x03ec7718,
void * 0x03ec9338, unsigned int 1, void * 0x0012e51c, int * 0x0012e518, int 0)
line 788 + 33 bytes
nsJSEventListener::HandleEvent(nsIDOMEvent * 0x03bdf9a4) line 154 + 64 bytes
nsXBLEventHandler::ExecuteHandler(nsXBLEventHandler * const 0x03cd3e40, const
nsString & {"click"}, nsIDOMEvent * 0x03bdf9a4) line 585
nsXBLEventHandler::MouseClick(nsIDOMEvent * 0x03bdf9a4) line 172 + 44 bytes
nsEventListenerManager::HandleEvent(nsIPresContext * 0x02fd01c0, nsEvent *
0x0012f4a8, nsIDOMEvent * * 0x0012f420, nsIDOMEventTarget * 0x03ccc050, unsigned
int 2, nsEventStatus * 0x0012f7b0) line 827 + 23 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x03ccc040, nsIPresContext *
0x02fd01c0, nsEvent * 0x0012f4a8, nsIDOMEvent * * 0x0012f420, unsigned int 2,
nsEventStatus * 0x0012f7b0) line 3381
nominating for beta2 and adding crash keyword
Keywords: crash, nsbeta2
I am seeing this too. Adding dogfood keyword. I think this is serious.
Keywords: dogfood
I don't think this is dogfood, since you don't really _need_ to collapse the
account. I couldn't reproduce it at all, using 54 folders on IMAP - how many
folders do you need?
In any case, reassigning to pinkerton
Assignee: trudelle → pinkerton
I am not sure this is debug only. I only have 10+ Imap folders. If this also 
happens on the release build and users experience crashes this may not be good.
Putting on [nsbeta2+][dogfood-] radar.  Does not need a fix ASAP for daily work, 
but we should fix this for beta2.
Whiteboard: [nsbeta2+][dogfood-]
It happens on both release and debug builds for me. I only have 11 folders in my
local mail and I see it using that. So it's not dependent on the # of folders.
Target Milestone: --- → M18
i'm seeing other weirdness with tooltips when collapsing mail accounts, it might 
be related. accepting, even though i can't dupe the exact problem.
Status: NEW → ASSIGNED
Severity: normal → major
*** Bug 43339 has been marked as a duplicate of this bug. ***
*** Bug 43524 has been marked as a duplicate of this bug. ***
*** Bug 43557 has been marked as a duplicate of this bug. ***
note to self:

I think this has to do with the fact that the tree is re-framing all of its rows 
when any rows are added/removed (such as when a folder opens/closes). This causes 
the frame that the tooltip listener is holding onto to go bye-bye and we go boom-
boom.
i landed changes to remove the reliance on the frame and instead holds onto the 
content node which isn't going away. since i couldn't ever duplicate this, i 
can't really tell it's fixed, but from looking at the code, i"m pretty certain 
that I fixed why it was crashing.

please reopen if this isn't truely fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
verified fixed mac/linux/win32 20000712nn builds -- I can't reproduce with 
the steps on this page or on the duplicate pages. 
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.