Closed Bug 6914 Opened 25 years ago Closed 25 years ago

Regression: Crash when send message twice using the same compose window

Categories

(MailNews Core :: Composition, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: fenella, Assigned: bugzilla)

Details

(Whiteboard: Should have a fix but hard to verify as it's hard to reproduce the crash)

RE: Linux build (1999-05-21-08m6)
Mac (1999-5-21-08m6)
steps:
1. Open mail compose window, type To: and subject field and content
2. Click send message.  No problem. Message is sent
3. Use the same compose window, send another message, seamonkey crashes.
Expected result: It does not send the second time. but it should not crash. In
the pass builds, it does nothing.
Mac: crash the system, no talkback
Here is the Linux stack trace:

#0  0x8356f25 in ?? ()
#1  0x40dda466 in nsTextEditor::OutputHTML ()
#2  0x40dda3ed in nsTextEditor::OutputHTML ()
#3  0x40de6707 in nsHTMLEditor::OutputHTML ()
#4  0x406e8bd7 in nsEditorAppCore::GetContentsAsHTML ()
#5  0x40728e31 in nsComposeAppCore::SendMessage2 ()
#6  0x40726068 in NS_MsgLoadMailtoUrl ()
#7  0x40327d82 in js_Invoke ()
#8  0x4032d9d6 in js_Interpret ()
#9  0x40327dd0 in js_Invoke ()
#10 0x4032d9d6 in js_Interpret ()
#11 0x40327dd0 in js_Invoke ()
#12 0x40327f75 in js_CallFunctionValue ()
#13 0x40312c99 in JS_CallFunctionValue ()
#14 0x402cd640 in nsJSEventListener::HandleEvent ()
#15 0x40962e09 in nsEventListenerManager::HandleEvent ()
#16 0x4078619d in RDFElementImpl::HandleDOMEvent ()
#17 0x409647be in nsEventStateManager::CheckForAndDispatchClick ()
#18 0x40963df9 in nsEventStateManager::PostHandleEvent ()
#19 0x4098a82d in PresShell::HandleEvent ()
#20 0x40bce38d in nsView::HandleEvent ()
#21 0x40bd5bed in nsViewManager::DispatchEvent ()
#22 0x40bcce3e in _init ()
#23 0x4009c566 in nsWidget::DispatchEvent ()
#24 0x4009c4bd in nsWidget::DispatchWindowEvent ()
#25 0x4009c5e3 in nsWidget::DispatchMouseEvent ()
#26 0x4009cbff in nsWidget::OnButtonReleaseSignal ()
#27 0x4009cecf in nsWidget::ButtonReleaseSignal ()
#28 0x80c3fdc in gtk_window_set_default_size ()
#29 0x809ce37 in gtk_signal_connect_object ()
#30 0x809c4be in gtk_signal_connect_object ()
#31 0x809abfa in gtk_selection_data_set ()
#32 0x80bc724 in gtk_widget_size_request ()
#33 0x8085d79 in gtk_get_current_event ()
#34 0x808531a in gtk_main_iteration_do ()
#35 0x80d31ab in gdk_input_add ()
#36 0x80e6130 in g_list_length ()
#37 0x80e65ab in g_list_length ()
#38 0x80e66c5 in g_main_iteration ()
#39 0x8084e2f in gtk_main ()
#40 0x4009281b in nsAppShell::Run ()
#41 0x40018da6 in nsAppShellService::Run ()
#42 0x8051313 in main ()

Have not tried windows yet
OS: Linux → All
Summary: seRegression: Crash when send message twice using the same compose window → Regression: Crash when send message twice using the same compose window
Win32 (1999-05-21-08 m6)
This problem also occurs on win_nt 4.0
will post the talkback stack trace later.
Status: NEW → ASSIGNED
Target Milestone: M7
Target Milestone: M7
Here is the window's stack track:

  0x021cf865
  nsTextEditor::OutputHTML
[d:\builds\seamonkey\mozilla\editor\base\nsTextEditor.cpp, line 1263]
  nsHTMLEditor::OutputHTML
[d:\builds\seamonkey\mozilla\editor\base\nsHTMLEditor.cpp, line 417]
  nsEditorAppCore::GetContentsAsHTML
[d:\builds\seamonkey\mozilla\xpfe\AppCores\src\nsEditorAppCore.cpp, line 1189]
  nsComposeAppCore::SendMessage2
[d:\builds\seamonkey\mozilla\mailnews\compose\src\nsComposeAppCore.cpp,
line       js_Interpret
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2200]
  js_Invoke
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 671]
  js_Interpret
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2200]
  js_Invoke
 [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 671]
  js_CallFunctionValue
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 736]
  JS_CallFunctionValue
[d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 2439]
  nsJSEventListener::HandleEvent
[d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp, line 98]
  nsEventListenerManager::HandleEvent
[d:\builds\seamonkey\mozilla\layout\events\src\nsEventListenerManager.cpp, line
565]
  RDFElementImpl::HandleDOMEvent
[d:\builds\seamonkey\mozilla\rdf\content\src\nsRDFElement.cpp, line 2255]
  nsEventStateManager::CheckForAndDispatchClick
[d:\builds\seamonkey\mozilla\layout\events\src\nsEventStateManager.cpp, line
574]
  nsEventStateManager::PostHandleEvent
[d:\builds\seamonkey\mozilla\layout\events\src\nsEventStateManager.cpp, line
169]
  PresShell::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 2032]
  nsView::HandleEvent
[d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 833]
  nsViewManager::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1733]
  HandleEvent
[d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 67]
  nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 414]
  nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 431]
 nsWindow::DispatchMouseEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2883]
 ChildWindow::DispatchMouseEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3030]
 nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2233]
 nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 475]
 USER32.dll + 0x13ed (0x77e713ed)

This crash occurs in single pop account and multiple identities
account.
Target Milestone: M6
Whiteboard: I am working on it...
Whiteboard: I am working on it... → Get a fix, waiting for check-in
The crash occurs in the editor when trying to extract the data because the web
shell was null (but not the nsComPtr).

This was due by the load of the url after sending a message to clear the body. I
have remove the LoadUrl code from the
JavaScript but I discover another crash due this time to a buffer that was
release twice into message compose. I have
removed the wrong release and now everything works fine except that the body
isn't clear. But as it was always like that
(M5) and that normally we should close the window (thing that doesn't work yet),
I thing we can keep it like that.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
approved by chofmann, fix and check in
QA Contact: 4080 → 4112
Laurel - can you help Fenella verify this?  Fenella has a few other bugs that
she has to verify plus run the basic functional test. Thanks.
Status: RESOLVED → REOPENED
Well, there are mixed results:

Reopen -- Using 1999052516 on linux rh5.2: I can't type anything in the body of
the compose window after the first send.  When I do send the second time from
the same compose window typing addressee and new subject I crash.

OK -- Using 1999052517 on NT4.0: Seems to be OK. Can send 2 or 3 times from same
compose window, retyping body or not (the original body text doesn't clear from
the compose window on send).

OK? Reopen? -- Using 1999052516  on Mac OS 8.51:  Sending a second time is OK,
but I crashed on sending a 3rd time from the same compose window the first
verification try I made -- talkback tracking ID EIA11OWM.  Subsequent tries on
the mac didn't have a problem with 3 messages, whether or not I retyped the body
or left the remaining text there and sent again.

Will include stack traces in comments when I get them.
Linux:
#0  0x40d286c2 in nsEditor::GetPresShell ()
#1  0x40d32466 in nsTextEditor::OutputHTML ()
#2  0x40d323ed in nsTextEditor::OutputHTML ()
#3  0x40d3e707 in nsHTMLEditor::OutputHTML ()
#4  0x40700bd7 in nsEditorAppCore::GetContentsAsHTML ()
#5  0x40740e31 in nsComposeAppCore::SendMessage2 ()
#6  0x4073e068 in NS_MsgLoadMailtoUrl ()
#7  0x40329d82 in js_Invoke ()
#8  0x4032f9d6 in js_Interpret ()
#9  0x40329dd0 in js_Invoke ()
#10 0x4032f9d6 in js_Interpret ()
#11 0x40329dd0 in js_Invoke ()
#12 0x40329f75 in js_CallFunctionValue ()
#13 0x40314c99 in JS_CallFunctionValue ()
#14 0x402ce780 in nsJSEventListener::HandleEvent ()
#15 0x4097af99 in nsEventListenerManager::HandleEvent ()
#16 0x4079e345 in RDFElementImpl::HandleDOMEvent ()
#17 0x4097c94e in nsEventStateManager::CheckForAndDispatchClick ()
#18 0x4097bf89 in nsEventStateManager::PostHandleEvent ()
#19 0x409a2a11 in PresShell::HandleEvent ()
#20 0x40be638d in nsView::HandleEvent ()
#21 0x40bedbed in nsViewManager::DispatchEvent ()
#22 0x40be4e3e in _init ()
#23 0x4009c566 in nsWidget::DispatchEvent ()
#24 0x4009c4bd in nsWidget::DispatchWindowEvent ()
#25 0x4009c5e3 in nsWidget::DispatchMouseEvent ()
#26 0x4009cbff in nsWidget::OnButtonReleaseSignal ()
#27 0x4009cecf in nsWidget::ButtonReleaseSignal ()
#28 0x80c3fdc in gtk_window_set_default_size ()
#29 0x809ce37 in gtk_signal_connect_object ()
#30 0x809c4be in gtk_signal_connect_object ()
#31 0x809abfa in gtk_selection_data_set ()
#32 0x80bc724 in gtk_widget_size_request ()
#33 0x8085d79 in gtk_get_current_event ()
#34 0x808531a in gtk_main_iteration_do ()
#35 0x80d31ab in gdk_input_add ()
#36 0x80e6130 in g_list_length ()
#37 0x80e65ab in g_list_length ()
#38 0x80e66c5 in g_main_iteration ()
#39 0x8084e2f in gtk_main ()
#40 0x4009281b in nsAppShell::Run ()
#41 0x40018df6 in nsAppShellService::Run ()
#42 0x8051313 in main ()
(gdb)
Resolution: FIXED → ---
Mac OS - Talback incident 9041608:
Call Stack:    (Signature = stub_is_write_ready() b5b76273)
        stub_is_write_ready()  [nsStubContext.cpp, line 852]
        net_read_file_chunk()  [mkfile.c, line 877]
        net_ProcessFile() [mkfile.c, line 1327]
        NET_ProcessNet() [mkgeturl.c, line 3351]
        NET_PollSockets() [mkselect.c, line 298]
        nsNetlibService::NetPollSocketsCallback() [nsNetService.cpp, line 1270]
        TimerImpl::Fire()  [nsTimerMac.cpp, line 223]
        TimerPeriodical::RepeatAction() [nsTimerMac.cpp, line 335]
        Repeater::DoRepeaters()   [nsRepeater.cpp, line 110]
        nsMacMessagePump::DispatchEvent()  [nsMacMessagePump.cpp, line 334]
        nsMacMessagePump::DoMessagePump()  [nsMacMessagePump.cpp, line 227]
        nsAppShell::Run()  [nsAppShell.cpp, line 90]
        nsAppShellService::Run()   [nsAppShellService.cpp, line 400]
        main()   [nsAppRunner.cpp, line 482]
Status: REOPENED → ASSIGNED
Whiteboard: Get a fix, waiting for check-in
Looks like the mac problem is unrelated... can't reproduce crash with many
verification attempts over several profiles on mac.
This is probably a silly question, but should we maybe be looking at the bug
that doesn't let us close the compose window after sending (if indeed that bug
is still around) since even being able to send twice is just an artifact of the
fact that the compose window isn't being closed and the send button not greyed
out?

In 4.x we had all sorts of problems if the user clicked send on a compose window
that had already sent, because some things were already deleted on the
assumption that the window would be going away soon.  So we disabled the send
button as soon as the user clicked on it so that it couldn't be clicked a second
time.
I was able to reproduce the crash with last evening build on Mac when send a
message the third time. With today Mac build in Debug mode I don't crash but I
found that we have a block bounds overwritten each time I send a message (even
from a brand new compose window).

The memory overwritten is cause by the folowwing call from Ender:

file mozilla/editor/base/nsTextEditor.cpp, line 1319:

if (NS_OK == rv){
  parser->RegisterDTD(dtd);
  parser->Parse(buffer, 0, "text/xif",PR_FALSE,PR_TRUE); << this cause the
problem!
}

I would not be surprised if this memory overwritten can be the cause of the
crash. In any case we need to fix that and see if that fix the crash as well.
Assignee: ducarroz → kostello
Status: ASSIGNED → NEW
Component: Front End → Editor
Product: MailNews → Browser
reassigne to ender folk.
more info:

at one point, nsHTMLContentSinkStream::EnsureBufferSize() is called. This
routine delete mBuffer even when mBuffer is null as it the case.
Assignee: kostello → ducarroz
Component: Editor → Composition
Product: Browser → MailNews
reassign the bug to myself as is not anymore an ender bug bug an HTML parser one
Status: NEW → ASSIGNED
Whiteboard: Should have a fix but hard to verify as it's hard to reproduce the crash
I have asked Seth to try to reproduce the crash on Unix and then to apply the
following path to see if that fix the bug:

? output.txt
Index: nsHTMLContentSinkStream.cpp
===================================================================
RCS file: /cvsroot/mozilla/htmlparser/src/nsHTMLContentSinkStream.cpp,v
retrieving revision 3.35
diff -r3.35 nsHTMLContentSinkStream.cpp
512c512,513
<     delete [] mBuffer;
---
> 	if (mBuffer)
> 	  delete [] mBuffer;
Like Akkana wisely suggested, we should fix the bug where the compose window
gets closed after sending a message.

At this point, I would prefer not to fix this in M6 and release note that the
compose window needs to be manually closed after each send.
<asked verah to add to release notes for M6>
I agree with lisa / akkana.  the real bug is the window doesn't close on send.

the profile people have figured out how to do this.  (the finished button in the
profile manager closes the window without crashing, right?)

I talked to jfd and he said he is going to work on getting the window to close
on send.

testing what happens if we send twice with the same compose window is not
worth-while, as eventually the application won't even allow the user to do this.

(in this case, however, jfd may have found a bug in the html parser.) I'm
working with him on verifying that.
I have filled bug http://bugzilla.mozilla.org/show_bug.cgi?id=7161 for the close
problem of the compose window
Target Milestone: M6 → M7
moving to m7
I verified that this problem no longer exists on all 3 platforms (Linux, Win_nt
4.0 and Mac) on the 5/28 m7 build.
Linux (1999-05-28-08-m7)
Win32 (1999-05-28-08 m7)
Mac (1999-05-28-08 M7)
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
Marking verified (worksforme).  Can't crash using jun01 unix/linux rh5.2.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.