Closed Bug 43634 Opened 24 years ago Closed 24 years ago

After mail send, select folder, or sorting, get virtual c function error

Categories

(MailNews Core :: Composition, defect, P3)

Product:
MailNews Core
Component:
Composition
Platform:
x86
Windows 98
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: doronr, Assigned: hyatt)

References

Details

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

Ok, i deleted profile, isntalled the newest mozilal build, created a pop3 
account, sent a message to myself and got it.

I then clicked on local folders, and get this win32 popup:

Microsoft Visual c++ runtime library
runtime error
program c:\mozilla\bin\mozilla.exe

r6025
-pure virtual function call

this is reproducable for me.
I get the same error when I double click on a message with 3 pane mode.
I get these often in various places; it's usually a build error that'll clear 
up in a couple cycles.
Doron - does this happen with another new profile you created?  What happens if 
you don't click local folders?  Does it really matter if you have to send a 
message first?
Keywords: crash
Using Build 2000-06-22 M17 on NT4

Steps to reproduce:
1) Launch Mail with an IMAP account
2) On Main mail window, click on size in the size column
3) Close Mail Client and launch it again, you will see that the messages 
are sorted by size
4) Now click on Date in the Date Column
5) And click on size again in the size column

Actual : System crashes with runtime error. Same as above.
Expected: Messages get sorted by size.




Reproduced Pratik's steps on 6/23 win32 commercial build.  Have not been able to 
reproduce Doron's steps yet.  Should I file a separate bug?  I may do so later 
as we get more info.

cc: putterman
2000062408 win32

Here is how I can repoduce this, on a fesh isntall and profile kill:

1. create a pop account
2. send yourself a email
3. open the email by double clicking on it
4. open the local folder by double clicking

expected is a crash, virtual c blabla.

note on the sorting - i saw it crashing yesterday, today i can't seem to get it
crashing.


I'll look at this. These might be separate bugs, but probably not. My guess is a 
bad cast in the tree control code (just because that's what it was last time we 
had one of these :-) )
Assignee: ducarroz → bienvenu
Here's the crash stack.  In nsIBox::AddCSSCollapsed, frame is null. Hence, we 
crash. I can check for null so that we don't crash. I don't know what will 
happen after that. CC'ing hyatt and evaughan (not really sure who in layout 
wants to know about this - if there's someone else that should know about it, 
please add them to the cc'list).

NMSG_WRITE(int 0x000000ff) line 221
_FF_MSGBANNER() line 169 + 10 bytes
_amsg_exit(int 0x00000019) line 324
_purecall() line 35 + 7 bytes
nsIBox::AddCSSCollapsed(nsBoxLayoutState & {...}, nsIBox * 0x042b29ec, int & 
0x00000000) line 1291
nsBox::IsCollapsed(nsBox * const 0x042b29ec, nsBoxLayoutState & {...}, int & 
0x00000000) line 979 + 17 bytes
nsContainerBox::GetPrefSize(nsContainerBox * const 0x042b29ec, nsBoxLayoutState 
& {...}, nsSize & {...}) line 437
nsBoxSizeListNodeImpl::GetBoxSize(nsBoxLayoutState & {...}, int 0x00000000) line 
421
nsBoxSizeListImpl::GetBoxSize(nsBoxLayoutState & {...}, int 0x00000000) line 382 
+ 22 bytes
nsBoxSizeListImpl::GetBoxSize(nsBoxLayoutState & {...}, int 0x00000000) line 382 
+ 22 bytes
nsBoxSizeListImpl::GetBoxSize(nsBoxLayoutState & {...}, int 0x00000000) line 382 
+ 22 bytes
nsObeliskLayout::GetMinSize(nsObeliskLayout * const 0x03bbfd20, nsIBox * 
0x036ac8bc, nsBoxLayoutState & {...}, nsSize & {...}) line 197 + 25 bytes
nsContainerBox::GetMinSize(nsContainerBox * const 0x036ac8bc, nsBoxLayoutState & 
{...}, nsSize & {...}) line 483 + 38 bytes
nsBoxFrame::GetMinSize(nsBoxFrame * const 0x036ac8bc, nsBoxLayoutState & {...}, 
nsSize & {...}) line 808 + 20 bytes
nsSprocketLayout::GetMinSize(nsSprocketLayout * const 0x03bbffe0, nsIBox * 
0x036ac5ec, nsBoxLayoutState & {...}, nsSize & {...}) line 1268
nsTempleLayout::GetMinSize(nsTempleLayout * const 0x03bbffe0, nsIBox * 
0x036ac5ec, nsBoxLayoutState & {...}, nsSize & {...}) line 241
nsContainerBox::GetMinSize(nsContainerBox * const 0x036ac5ec, nsBoxLayoutState & 
{...}, nsSize & {...}) line 483 + 38 bytes
nsBoxFrame::GetMinSize(nsBoxFrame * const 0x036ac5ec, nsBoxLayoutState & {...}, 
nsSize & {...}) line 808 + 20 bytes
nsStackLayout::GetMinSize(nsStackLayout * const 0x03baf410, nsIBox * 0x036ac54c, 
nsBoxLayoutState & {...}, nsSize & {...}) line 123
nsContainerBox::GetMinSize(nsContainerBox * const 0x036ac54c, nsBoxLayoutState & 
{...}, nsSize & {...}) line 483 + 38 bytes
nsBoxFrame::GetMinSize(nsBoxFrame * const 0x036ac54c, nsBoxLayoutState & {...}, 
nsSize & {...}) line 808 + 20 bytes
nsContainerBox::GetPrefSize(nsContainerBox * const 0x036ac54c, nsBoxLayoutState 
& {...}, nsSize & {...}) line 456
nsBoxFrame::GetPrefSize(nsBoxFrame * const 0x036ac54c, nsBoxLayoutState & {...}, 
nsSize & {...}) line 770 + 20 bytes
nsSprocketLayout::GetPrefSize(nsSprocketLayout * const 0x00d5d140, nsIBox * 
0x036ac4bc, nsBoxLayoutState & {...}, nsSize & {...}) line 1201
nsContainerBox::GetPrefSize(nsContainerBox * const 0x036ac4bc, nsBoxLayoutState 
& {...}, nsSize & {...}) line 447 + 38 bytes
nsBoxFrame::GetPrefSize(nsBoxFrame * const 0x036ac4bc, nsBoxLayoutState & {...}, 
nsSize & {...}) line 770 + 20 bytes
nsSprocketLayout::GetPrefSize(nsSprocketLayout * const 0x00d5d140, nsIBox * 
0x036eb8e0, nsBoxLayoutState & {...}, nsSize & {...}) line 1201
nsContainerBox::GetPrefSize(nsContainerBox * const 0x036eb8e0, nsBoxLayoutState 
& {...}, nsSize & {...}) line 447 + 38 bytes
nsBoxFrame::GetPrefSize(nsBoxFrame * const 0x036eb8e0, nsBoxLayoutState & {...}, 
nsSize & {...}) line 770 + 20 bytes
nsSprocketLayout::PopulateBoxSizes(nsIBox * 0x038331d4, nsBoxLayoutState & 
{...}, nsBoxSize * & 0x027d1918, nsComputedBoxSize * & 0x00000000, int & 
0x00001f2c, int & 0x40000000, int & 0x00000000) line 695
nsSprocketLayout::Layout(nsSprocketLayout * const 0x00d5d140, nsIBox * 
0x038331d4, nsBoxLayoutState & {...}) line 142
nsContainerBox::Layout(nsContainerBox * const 0x038331d4, nsBoxLayoutState & 
{...}) line 556 + 34 bytes
nsBoxFrame::Layout(nsBoxFrame * const 0x038331d4, nsBoxLayoutState & {...}) line 
882 + 13 bytes
nsStackLayout::Layout(nsStackLayout * const 0x00d5ce70, nsIBox * 0x03833144, 
nsBoxLayoutState & {...}) line 245
nsContainerBox::Layout(nsContainerBox * const 0x03833144, nsBoxLayoutState & 
{...}) line 556 + 34 bytes
nsBoxFrame::Layout(nsBoxFrame * const 0x03833144, nsBoxLayoutState & {...}) line 
882 + 13 bytes
nsBoxFrame::Reflow(nsBoxFrame * const 0x0383310c, nsIPresContext * 0x031dff00, 
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 
0x00000000) line 723
nsRootBoxFrame::Reflow(nsRootBoxFrame * const 0x0383310c, nsIPresContext * 
0x031dff00, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, 
unsigned int & 0x00000000) line 211
nsContainerFrame::ReflowChild(nsIFrame * 0x0383310c, nsIPresContext * 
0x031dff00, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 
0x00000000, int 0x00000000, unsigned int 0x00000000, unsigned int & 0x00000000) 
line 693 + 31 bytes
ViewportFrame::Reflow(ViewportFrame * const 0x038330d0, nsIPresContext * 
0x031dff00, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, 
unsigned int & 0x00000000) line 546
nsHTMLReflowCommand::Dispatch(nsHTMLReflowCommand * const 0x05950220, 
nsIPresContext * 0x031dff00, nsHTMLReflowMetrics & {...}, const nsSize & {...}, 
nsIRenderingContext & {...}) line 145
PresShell::ProcessReflowCommands(int 0x00000000) line 4094
PresShell::FlushPendingNotifications(PresShell * const 0x031d9ad0) line 3219
nsXULDocument::FlushPendingNotifications(nsXULDocument * const 0x031de810) line 
1959
Status: NEW → ASSIGNED
checking for null doesn't help - we've already crashed by this point - I, or the 
debugger, was confused. There's something confused about the nsIBox. I think the 
vtable has been written into - I'll get Purify up and going.
nominate nsbeta2.  I hear that pure virtual function calls are bad crashes and 
there may be something very bad going on underneath it all.
Keywords: nsbeta2
Summary: [crash] after mail send on pop, virtual c function error → [crash] after mail send on pop or sorting, virtual c function error
I spent all day trying to get Purify running on my release build with symbols. 
It's not working. I'll have to try at my work machine tomorrow. If that doesn't 
work, I'm going to have to throw this over to whoever's code is actually having 
the problem.
Putting on [nsbeta2+] radar for beta2 fix, but only to fix the crash found by 
Doron.  As for the sorting, if that is a separate problem, please log a separate 
bug and nominate that one.
Whiteboard: [nsbeta2+]
I can't reproduce Doron's crash, but I have no problem reproducing the sort one,
and have run into it actually using the product.  I got purify working here, but
it didn't show any red, so I can't tell that someone is writing into the vtable.
It could just be a bad cast. I'll probably have to give this to someone with a
clue about the code on the stack.
David - do you think that the sorting crash is fairly common for a user to get?
It's a sign of something wrong in some code somewhere. Since it looks like
layout code, my guess is that it could bite people in different ways so we
should fix it if we can.
I also saw this when clicking on a twisty in the bookmarks windows.
*** Bug 43564 has been marked as a duplicate of this bug. ***
I pulled a new tree at 5PM today and this seems to be fixed! I'll keep trying
but I haven't been able to get it to crash yet.
I can get this to crash by sorting the default profile bookmarks three times - 
e.g., added, last visited, added again. 

Complete steps, starting with default profile (or any profile, is my guess)

1. Sort by added by clicking on the added column header.
2. Sort by last visited.
3. Sort by added again (or probably any column - sorting by description also 
crashed)

Assigning to evaughan since the box code seems to the place to start. Let me 
know if you can't reproduce this. 

Adding rjc to cc list in case he gets bookmark bugs filed against him.
Assignee: bienvenu → evaughan
Status: ASSIGNED → NEW
Target Milestone: --- → M18
*** Bug 44130 has been marked as a duplicate of this bug. ***
I just got

Microsoft Visual C++ Runtime Library, Runtime Error!, R6025 - pure virtual
function call.

After pressing the delete key to try and delete a bit of mail.
Using 2000063008 win32-installer on windows 95.
The delete causing the pure virtual func call is bug 
http://bugzilla.mozilla.org/show_bug.cgi?id=44349.
Sorry for spam, adding myself to the CC: list of the particularly nasty bug.
*** Bug 44349 has been marked as a duplicate of this bug. ***
adding to mostfreq keyword list to minimize dup bugs filed (hopefully)
Keywords: mostfreq
*** Bug 44858 has been marked as a duplicate of this bug. ***
I assigned evaughan another bug about a pure virtual method call in
nsIBox::AddCSSCollapsed involving reading AOL mail. It's probably a duplicate of
this one. 
...
Assignee: evaughan → hyatt
*** Bug 44583 has been marked as a duplicate of this bug. ***
*** Bug 43953 has been marked as a duplicate of this bug. ***
Summary: [crash] after mail send on pop or sorting, virtual c function error → After mail send, select folder, or sorting, get virtual c function error
David, does it look like you'll be able to get a fix in?
Fixed. (hyatt does a happy dance.)
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Thanks David. Good job...
Qa-assign to myself
QA Contact: lchiang → fenella
Linux (2000-07-17-08 M17)
Win32 (2000-07-17-09 M17)
Mac (2000-07-17-08 M17
I have tried all scenarios as described in this bug. No problem, the bug is
fixed.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.