Overview Description: Crashes when I try to close the compose window while replying to a message. Steps to Reproduce: 1. Start Messenger. 2. Select a msg. Click 'Reply'. 3. Close the compose window by clicking little 'X' button. Crashes. Build date and platform: 1999-11-03-13-M11, Windows commercial build. Additional info: 1. The crash is NOT consistent. 2. Try repeating the steps 2 and 3 few more times. 3. No stack trace available.

I can reproduce this crash on my Windows debug build. The crash occurs when window is destroyed in nsGenericHTMLContainerElement::~nsGenericHTMLContainerElement() it try to delete a "kid" which has apparently been already destroyed!

I crash only if you are in HTML composition and if you don't edit the body. I cannot reproduce it on my Mac.

call stack: nsGenericHTMLContainerElement::~nsGenericHTMLContainerElement() line 2396 + 9 bytes nsBodyInner::~nsBodyInner() line 140 + 8 bytes nsHTMLBodyElement::~nsHTMLBodyElement() line 574 + 11 bytes nsHTMLBodyElement::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsHTMLBodyElement::Release(nsHTMLBodyElement * const 0x03457bb0) line 578 + 137 bytes nsGenericHTMLContainerElement::~nsGenericHTMLContainerElement() line 2396 + 12 bytes nsHTMLHtmlElement::~nsHTMLHtmlElement() line 101 + 11 bytes nsHTMLHtmlElement::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsHTMLHtmlElement::Release(nsHTMLHtmlElement * const 0x03491410) line 105 + 134 bytes nsDocument::~nsDocument() line 625 + 27 bytes nsMarkupDocument::~nsMarkupDocument() line 47 + 8 bytes nsHTMLDocument::~nsHTMLDocument() line 256 + 23 bytes nsHTMLDocument::`scalar deleting destructor'() + 15 bytes nsDocument::Release(nsDocument * const 0x03497570) line 750 + 138 bytes nsHTMLDocument::Release(nsHTMLDocument * const 0x03497570) line 296 nsCOMPtr<nsIDocument>::~nsCOMPtr<nsIDocument>() line 470 DocumentViewerImpl::~DocumentViewerImpl() line 275 + 66 bytes DocumentViewerImpl::`scalar deleting destructor'(unsigned int 1) + 15 bytes DocumentViewerImpl::Release(DocumentViewerImpl * const 0x03491c10) line 217 + 134 bytes nsWebShell::Destroy(nsWebShell * const 0x033f8dd0) line 1167 + 27 bytes nsHTMLFrameInnerFrame::~nsHTMLFrameInnerFrame() line 434 nsHTMLFrameInnerFrame::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsFrame::Destroy(nsFrame * const 0x033f8fc0, nsIPresContext & {...}) line 370 + 34 bytes nsFrameList::DestroyFrames(nsIPresContext & {...}) line 32 nsContainerFrame::Destroy(nsContainerFrame * const 0x033cb7d0, nsIPresContext & {...}) line 92 nsFrameList::DestroyFrames(nsIPresContext & {...}) line 32 nsContainerFrame::Destroy(nsContainerFrame * const 0x024c12b0, nsIPresContext & {...}) line 92 nsFrameList::DestroyFrames(nsIPresContext & {...}) line 32 nsContainerFrame::Destroy(nsContainerFrame * const 0x02ec1a60, nsIPresContext & {...}) line 92 nsFrameList::DestroyFrames(nsIPresContext & {...}) line 32 nsContainerFrame::Destroy(nsContainerFrame * const 0x02ec2050, nsIPresContext & {...}) line 92 ViewportFrame::Destroy(ViewportFrame * const 0x02ec2050, nsIPresContext & {...}) line 134 FrameManager::~FrameManager() line 337 FrameManager::`scalar deleting destructor'(unsigned int 1) + 15 bytes FrameManager::Release(FrameManager * const 0x035ff300) line 322 + 134 bytes PresShell::~PresShell() line 556 + 27 bytes PresShell::`scalar deleting destructor'() + 15 bytes PresShell::Release(PresShell * const 0x035ff840) line 487 + 138 bytes nsCOMPtr<nsIPresShell>::~nsCOMPtr<nsIPresShell>() line 470 DocumentViewerImpl::~DocumentViewerImpl() line 275 + 22 bytes DocumentViewerImpl::`scalar deleting destructor'(unsigned int 1) + 15 bytes DocumentViewerImpl::Release(DocumentViewerImpl * const 0x035f8ab0) line 217 + 134 bytes nsWebShell::Destroy(nsWebShell * const 0x0367f300) line 1167 + 27 bytes nsWebShellWindow::Close(nsWebShellWindow * const 0x0367f8a0) line 485 nsWebShellWindow::HandleEvent(nsGUIEvent * 0x0012f834) line 540 nsWindow::DispatchEvent(nsWindow * const 0x0367f764, nsGUIEvent * 0x0012f834, nsEventStatus & nsEventStatus_eIgnore) line 403 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f834) line 424 nsWindow::DispatchStandardEvent(unsigned int 101) line 439 + 15 bytes nsWindow::OnDestroy() line 3184 nsWindow::ProcessMessage(unsigned int 2, unsigned int 0, long 0, long * 0x0012fa1c) line 2461 nsWindow::WindowProc(HWND__ * 0x000b05da, unsigned int 2, unsigned int 0, long 0) line 581 + 27 bytes USER32! 77e719d0() USER32! 77e71982() NTDLL! 77f763a3() USER32! 77e718d2() USER32! 77e727fe() USER32! 77e72889() nsWindow::WindowProc(HWND__ * 0x000b05da, unsigned int 16, unsigned int 0, long 0) line 588 + 31 bytes USER32! 77e719d0() USER32! 77e71982() NTDLL! 77f763a3() USER32! 77e718d2() USER32! 77e727fe() USER32! 77e72889() nsWindow::WindowProc(HWND__ * 0x000b05da, unsigned int 274, unsigned int 61536, long 655982) line 588 + 31 bytes USER32! 77e719d0() USER32! 77e71982() NTDLL! 77f763a3() USER32! 77e718d2() USER32! 77e727fe() USER32! 77e72889() nsWindow::WindowProc(HWND__ * 0x000b05da, unsigned int 161, unsigned int 20, long 655982) line 588 + 31 bytes

Reassign to Ender team for investigation. Pass it down (XPApp?) if itsn't yours...

Steve took a look and it seems that the error is occurring in layout code. Assigning the bug to Nisheeth

*** Bug 18096 has been marked as a duplicate of this bug. ***

*** Bug 18053 has been marked as a duplicate of this bug. ***

Add Dogfood in summary.

Nominating for Dogfood. People obviously run into this since we've gotten two duplicate bug reports on this problem already. People can easily start to reply to a message and then change their mind and close the window.

In case of bug 18053, the user crash after he/she send the message.

Accepting bug...

Putting on PDT+ radar.

I'm trying to reproduce this on a recent windows NT 4.0 debug build and am unable to do so. I'm not going to close this bug out as worksforme just yet because Suresh mentioned that this crash is not consistent. Suresh, can you reproduce this crash on the latest builds? If this is hard to reproduce, maybe this shouldn't be PDT+.

I still crash sometime on Mac today. But I don't have a reproducible case. Momoi also complains today that he get the crash. Momoi, do you have more info how to reproduce it?

Hmmm, I couldn't reproduce using 11/08 windows Commercial build, but I *could* reproduce using 11/09 windows commercial build.

I'm crashing consistently on 11/9/99 Win32 build (1999110911). It's pretty easy to reproduce this on a Windows NT or 98 ( so far). 1. (This problem will probably happen with any msg but here's a small mailbox (5 msgs in all) which we use for internaitonal testing. The first one (date-sorted) is a msg in Latin 1. http://rocknroll/users/momoi/publish/seamonkey/smoketest.zip 2. Put this in your POP mail directory or copy it from there to a IMAP server. 3. Start up Mozilla and open Messenger. 4. Ascertain that mail send option is to set to HTML on a particular server on which this mailbox is placed. 5. Select the first msg in Latin 1. 6. Engage the "Reply" button and see that the HTML compose window gets drawn completely with quoting. 7. Click on the upper-right corner to close this window and see Mozilla crash. 8. If a crash does ton happen in Step 7, try steps 5-7 again. I have not had to do this more than once (one repeat) to induce this crash. Usually no repeat is necessary.

Momoi worked with me and helped reproduce this. I was using plain text mail compose which is why the bug wasn't showing up for me. I can reproduce the crash now. I'll work on this tomorrow morning and update this bug with what I find.

Update: I can crash consistantly on all three platforms using the 19991109 builds using the menu item File|Close. Previous commments mention the Close icon in the title bar, but I can crash using the menu item.

The problem here is that the body content object is getting freed prematurely. I've started a unix build so that I can track this down using waterson's refcount balancer.

it would be great if we could fix this but I don't want to hold m11 any longer. since the crash occurs only when no text has been entered and there is no data loss directly from this quit/exit action I think we can live with it in m11. nisheeth is working on the fix and it should come early in m12.

Work on this bug is blocked until bug 18743 gets fixed. The latest builds crash while trying to bring up the mail compose window.

*** Bug 19252 has been marked as a duplicate of this bug. ***

*** Bug 18937 has been marked as a duplicate of this bug. ***

The problem here was in nsHTMLEditor::DeleteSelectionAndCreateNode(). The code was missing an ADDREF on a ref-counted out param. Adding the AddRef fixes the crash. Man, I've spent three whole days tracking this down and the fix turns out to be a one-liner! :-) I've sent the fix for a code review. I'll check it in once it gets approved.

Great job, thanks nisheeth.

Index: nsHTMLEditor.cpp =================================================================== RCS file: /cvsroot/mozilla/editor/base/nsHTMLEditor.cpp,v retrieving revision 1.186 diff -c -r1.186 nsHTMLEditor.cpp *** nsHTMLEditor.cpp 1999/11/18 19:43:14 1.186 --- nsHTMLEditor.cpp 1999/11/21 11:11:34 *************** *** 1634,1639 **** --- 1634,1640 ---- getter_AddRefs(newNode)); // XXX: ERROR_HANDLING check result, and make sure aNewNode is set correctly in success/failure cases *aNewNode = newNode; + NS_IF_ADDREF(*aNewNode); // we want the selection to be just after the new node nsCOMPtr<nsIDOMSelection> selection;

Index: nsHTMLEditor.cpp =================================================================== RCS file: /cvsroot/mozilla/editor/base/nsHTMLEditor.cpp,v retrieving revision 1.186 diff -c -r1.186 nsHTMLEditor.cpp *** nsHTMLEditor.cpp 1999/11/18 19:43:14 1.186 --- nsHTMLEditor.cpp 1999/11/21 11:11:34 *************** *** 1634,1639 **** --- 1634,1640 ---- getter_AddRefs(newNode)); // XXX: ERROR_HANDLING check result, and make sure aNewNode is set correctly in success/failure cases *aNewNode = newNode; + NS_IF_ADDREF(*aNewNode); // we want the selection to be just after the new node nsCOMPtr<nsIDOMSelection> selection;

I just checked in the fix.

esther, can you verify this? Thanks.

Using build 1999112209m12 on win98 and linux and 1999112208m12 on mac this is fixed. No crash selecting Close with menu item or by clicking on the close icon in title bar. Verified