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

VERIFIED WORKSFORME

Status

MailNews Core
Composition
P3
critical
VERIFIED WORKSFORME
19 years ago
9 years ago

People

(Reporter: fenella, Assigned: Jean-Francois Ducarroz)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

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

(Reporter)

Description

19 years ago
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
(Reporter)

Updated

19 years ago
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
(Reporter)

Comment 1

19 years ago
Win32 (1999-05-21-08 m6)
This problem also occurs on win_nt 4.0
will post the talkback stack trace later.
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M7
(Reporter)

Updated

19 years ago
Target Milestone: M7
(Reporter)

Comment 2

19 years ago
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.
(Assignee)

Updated

19 years ago
Target Milestone: M6
(Assignee)

Updated

19 years ago
Whiteboard: I am working on it...
(Assignee)

Updated

19 years ago
Whiteboard: I am working on it... → Get a fix, waiting for check-in
(Assignee)

Comment 3

19 years ago
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.
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 4

19 years ago
approved by chofmann, fix and check in

Updated

19 years ago
QA Contact: 4080 → 4112

Comment 5

19 years ago
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.

Updated

19 years ago
Status: RESOLVED → REOPENED

Comment 6

19 years ago
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.

Comment 7

19 years ago
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)

Updated

19 years ago
Resolution: FIXED → ---

Comment 8

19 years ago
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]
(Assignee)

Updated

19 years ago
Status: REOPENED → ASSIGNED
Whiteboard: Get a fix, waiting for check-in

Comment 9

19 years ago
Looks like the mac problem is unrelated... can't reproduce crash with many
verification attempts over several profiles on mac.

Comment 10

19 years ago
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.
(Assignee)

Comment 11

19 years ago
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)

Updated

19 years ago
Assignee: ducarroz → kostello
Status: ASSIGNED → NEW
Component: Front End → Editor
Product: MailNews → Browser
(Assignee)

Comment 12

19 years ago
reassigne to ender folk.
(Assignee)

Comment 13

19 years ago
more info:

at one point, nsHTMLContentSinkStream::EnsureBufferSize() is called. This
routine delete mBuffer even when mBuffer is null as it the case.
(Assignee)

Updated

19 years ago
Assignee: kostello → ducarroz
Component: Editor → Composition
Product: Browser → MailNews
(Assignee)

Comment 14

19 years ago
reassign the bug to myself as is not anymore an ender bug bug an HTML parser one
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Whiteboard: Should have a fix but hard to verify as it's hard to reproduce the crash
(Assignee)

Comment 15

19 years ago
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;

Comment 16

19 years ago
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.

Comment 17

19 years ago
<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.
(Assignee)

Comment 19

19 years ago
I have filled bug http://bugzilla.mozilla.org/show_bug.cgi?id=7161 for the close
problem of the compose window

Updated

19 years ago
Target Milestone: M6 → M7

Comment 20

19 years ago
moving to m7
(Reporter)

Comment 21

19 years ago
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)
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → WORKSFORME

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 22

19 years ago
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.