Closed Bug 5793 Opened 25 years ago Closed 25 years ago

Close the compose window after a send results in a crash

Categories

(SeaMonkey :: MailNews: Message Display, defect, P3)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
All
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: lchiang, Assigned: bugzilla)

Details

Close the compose window after a send results in a crash

Talkback tracking ID:  D4N00XXJ and D4N12SUI

Release build from directory dated: 1999-04-30-08
Windows NT 4.0

1)  Start apprunner
2)  Tasks | Messenger
3)  New Message
4)  Address the message and enter a subject
5)  Click Send.  Message is sent
6)  Compose window is still open (due to another bug that the compose window
doesn't close after send)
7)  Close the compose window
8)  Crash occurs.

I have to go and try this on Linux and Mac and will have results shortly.  Until
I find out the results, I cannot say whether this occurs on all platforms or
not.
Target Milestone: M5
set target milestone to M5.  Does anyone see this?

Also, the prefs50.js file I used only has one POP account in it so I took out
any factors of having more than one account.
Status: NEW → ASSIGNED
same for me on Mac, with a today fresh build
Hardware: PC → All
Changing platform to ALL since this occurs on Mac and Win32 so far.  I have to
try Linux next.
This is the stack I get

nsCaret::GetViewForRendering(nsPoint & {x=435 y=345}, nsIView * & 0x00000000)
line 431 + 17 bytes
nsCaret::DrawCaret() line 516
nsCaret::CaretBlinkCallback(nsITimer * 0x042d25d0, void * 0x042a9f60) line 577
TimerImpl::Fire(unsigned long 16924421) line 308 + 17 bytes
TimerImpl::ProcessTimeouts(unsigned long 16924421) line 187
FireTimeout(HWND__ * 0x00000000, unsigned int 275, unsigned int 30520, unsigned
long 16924421) line 101 + 9 bytes
USER32! 77e7128c()
nsAppShellService::Run(nsAppShellService * const 0x01011950) line 187
main(int 6, char * * 0x00fe1750) line 447 + 12 bytes
mainCRTStartup() line 338 + 17 bytes

It crashes on
		theView->GetPosition(&x, &y);
where the View is pointing to a destroyed vtable.

It looks like a timer needs to be killed before the view goes away.  I'm cc'ing
sfraser since it looks like he might be the owner of the file nsCaret.cpp.  Any
ideas Simon?
This is almost certainly a dup of bug 3914, which in turn was caused by bug 4127.
After the leak fix checkins last night, things have changed now, and the caret
should be being freed properly. If the pres shell is being freed, then the caret
will take care of itself. If you guys have leaks that cause the pres shell to be
leaked, then you will see this crash.

Note that some new problems have showed up when closing the editor window,
after the leak fixes (bug 5796). We're working on those.
Can we reproduce this problem without sending the message? If not, It might have something to do with the send
code! I cannot test it right know because am rebuilding the project on my both machines...
I crash when just opening a compose window and closing a compose window.  I
don't need to send a message.
See bug 5796 that sfraser references.  This appears to be an editor problem.
The only thing that sfraser says that perhaps you guys should check out may be:
"If you guys have leaks that cause the pres shell to be leaked, then you will
see this crash"  Just a thought.
On April 30 PowerPC build (1999043009) I crash when just opening a compose
window and closing a compose window.  I don't need to send a message.
A temporary fix for the editor close window crash follows:

Index: nsTextEditor.cpp
===================================================================
RCS file: /cvsroot/mozilla/editor/base/nsTextEditor.cpp,v
retrieving revision 1.61
diff -r1.61 nsTextEditor.cpp
137c137
< };
---
> }
143c143
< };
---
> }
153a154,159
>
>   // this is a hack to have mTypeInState as a member variable,
>   // but still be able to express the nsIDOMSelectionListener
>   // interface. This addref prevents anyone calling delete on the typeInState,
>   // which is bad.
>   mTypeInState.AddRef();

Try this.
Assuming I applied the patch correctly, it still crashes with the same stack.
Then it sounds like you are leaking the pres shell. Try a breakpoint on the
pres shell desctuctor. If you don't hit this on closing the window, then
life will still suck.
This is where my lack of raptor knowledge shows.  Where's the pres shell?
layout/html/base/src/nsPresShell.cpp
I hit the nsPresShell destructor.  I never hit the nsTextEditor destructor.
Whiteboard: investigating
I worked with putterman on this one. It appears that the pres shell containing
the blinking caret is never freed (there is > 1 pres shell per window), so
it still crashes. Fixing this would seem to require a review of ownership issues
throughout the mail/news code, and may be blocked by 5394.
This where I asked Jean-Francois to look at this since I'm not familiar with
this code.  There appear to be two webshell's getting created for the compose
window (I guess one is for the window and one is to host Ender?).  Anyway, only
one of these are getting destroyed and it's not the one that has the caret
that's causing the problem.
Target Milestone: M5 → M6
moving to m6
Doesn't make mail too user-friendly by leaving all the compose windows around
since closing them causes a crash.  It would be good to have this fixed for M5
since this behavior is a regression from Win32's M4 build.  But, chofmann, I
guess we have to ship M5 soon; thus, you've made this a M6 bug?

I'll update the release note bug to comment about this item then.
ducarroz doesn't have any quick fixes for this right now and he is
working on the Mac startup crash.
Looks like bug 5870 fixed recently by the Ender team may have fixed this.
putterman and ducarroz have verified in a very recent debug build on Win32 and
Mac.
Using released build 1999050317 on win95 this is fixed. Stacey states it's fixed
on linux 1999050317 build too.  Waiting for Mac to be verified.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Peter just verified this on both netscape and mozilla mac 5/3 builds.  This
appears to be fixed when 5870 was fixed.  Will resolve as fixed and verified per
lchiang.
Status: RESOLVED → VERIFIED
Target Milestone: M6 → M5
Since this bug was actually fixed in M5 and not M6, I'm correcting the target
milestone.
Whiteboard: investigating
clear the status.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.