111703 - opening email crashes mozilla

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[tabit]

This is a tricky one: For several versions it occurs from time to time that
opening a randomly selected email crashes the application completely. The
viewer-windows is seen empty for a while and then Dr. Watson & Talkback appear
and mozilla says "goodbye".

I can not tell you more than the numbers of all my Talkback-Data. There are 3 to
5 different occurences with a Talkback-description you can identify as something
like "opening email crashes mozilla":

No | kind | date

TB38417948X email-crash 23.11.2001
TB38320681E do not remember 21.11.2001
TB37989732Q email-crash 14.11.2001
TB37961661Y do not remember 13.11.2001
TB37833341K do not remember 10.11.2001
TB37833326M do not remember 10.11.2001

regards

tabit

Comment 1

[rolux]

could be related to bug 111237

look for recent talkback data bearing by
mail address, i've sent quite a lot...

Comment 2

[tabit]

Dear [e-mail],

I have read the description of
http://bugzilla.mozilla.org/show_bug.cgi?id=111237
but to me there seems to be no relation  with the problem I described. The
Emails I open which cause the crashes seem to be a random pick, no special
folder involved, no filtering rules involved (also no scripting, because I
switched it off, by the way).

I guess there must be some interaction between the email-display-module and some
other thing like incoming mail in the background. Some kind of memory leak I guess.

tabit

Comment 3

[tabit]

and again: TB38657770M

cold be related to bug 108425 !!!

Comment 4

[tabit]

another one: TB38703965M

annotation: The time between opening the email and the crash occuring can be
between 30 seconds and several minutes

Comment 5

[R.K.Aa.]

Reporter: Please remember to always include build ID in bug-reports.

Stephen: can you pull TB38657770M

Comment 6

[[e-mail] (gone - use [e-mail] instead)]

Stack Signature  nsProxyEventObject::GetInterfaceInfo 4b3f958f
Trigger Time 2001-12-05 22:00:51
Email Address [e-mail]
URL visited crash on opening email
User Comments
Build ID 2001112110
Product ID MozillaTrunk
Platform
Operating System Win32
Module
Trigger Reason Access violation
Stack Trace
nsProxyEventObject::GetInterfaceInfo
[d:\builds\seamonkey\mozilla\xpcom\proxy\src\nsProxyEventObject.cpp, line 528]
PrepareAndDispatch
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp,
line 68]
SharedStub
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp,
line 139]
nsSocketTransport::OnProgress
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsSocketTransport.cpp, line 1388] 

Comment 7

[tabit]

Build-IDs: Most of the time I use the nightly of today or the day before.
Because of Bug 112843 (crash on any program-exit) I changed back from 281120012
to 22112001, which I am actually using until I hear 112843 is fixed (no one
seems to care very much about fixing 112843 actually).

I guessed TB-Data include Build-numer do they not?

Comment 8

[tabit]

1. Another one: TB509294Q (gathered on nightly 22122001)
2. Question: Could bug 112843 be related to this one?

regards

tabit

Comment 9

[tabit]

Possibly the missing link between bug 112834 and bug 111703:

TB1134401X

Comment 10

[tabit]

I am a bit disappointed about the fact that this bug is not taken care of:

It still exists in 05012002:
TB1681761G (15.01.2002) &
TB1865627H (19.01.2002)

I can add to the description:

"as long as you leave open the email-windows that show nothing at all, the app
will not crash. But as soon as you close them mozilla will go down in flames."

regards

tabit

Comment 11

[scattol]

This seems to describe well what happens to me. Typically, 
me, or my girlfriend, tries to read a newly received email 
(shown as unread and at the top of the list) and then crashes immediately.
Doesn't always crash under these conditions, just some times. Mozilla
can also have been opened for a few hours before this occurs, but here
again, not always (I guess this depends on how often I get email

Comment 12

[David :Bienvenu]

If anyone has a message that reliably causes this crash, could they attach it to
the bug?

Here's a stack trace from talkback:
MSVCRT.DLL + 0x11186 (0x78011186)
nsUInt32Array::RemoveAt
[d:\builds\seamonkey\mozilla\mailnews\base\util\nsUInt32Array.cpp, line 247]
nsMsgMailSession::RemoveFolderListener
[d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgMailSession.cpp, line 109]
XPTC_InvokeByIndex
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp,
line 106]
XPCWrappedNative::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, line 2011]
XPC_WN_CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp,
line 1267]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 834]
js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2799]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 850]
js_InternalInvoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 925]
JS_CallFunctionValue [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 3407]
nsJSContext::CallEventHandler
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 1014]
nsJSEventListener::HandleEvent
[d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp, line 182]
nsEventListenerManager::HandleEventSubType
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1206]
nsEventListenerManager::HandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1881]
GlobalWindowImpl::HandleDOMEvent
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 638]
DocumentViewerImpl::Unload
[d:\builds\seamonkey\mozilla\content\base\src\nsDocumentViewer.cpp, line 1298]
nsDocShell::FireUnloadNotification
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 677]
nsDocShell::Destroy [d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp,
line 2467]
nsWebShell::Destroy [d:\builds\seamonkey\mozilla\docshell\base\nsWebShell.cpp,
line 1452]
nsXULWindow::Destroy
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsXULWindow.cpp, line 372]
nsWebShellWindow::Destroy
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWebShellWindow.cpp, line 1761]
nsWebShellWindow::Close
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWebShellWindow.cpp, line 389]
nsWebShellWindow::HandleEvent
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWebShellWindow.cpp, line 464]

Comment 13

[tabit]

TB2059831M (on build nightly 18012002)

Comment 14

[David :Bienvenu]

Attachment: proposed bulletproofing fix

we should be checking if the listener was found or not.

Comment 15

[David :Bienvenu]

Seth and Navin, can you review? Also, Seth, nsAddrBookSession needs the same
fix, which I will attach.

Comment 16

[David :Bienvenu]

Attachment: another place needing fixing.

Comment 17

[(not reading, please use [e-mail] instead)]

Comment on attachment 67925 [details] [diff] [review]
proposed bulletproofing fix

in this case, you should use -1.  the nsVoidArray code doesn't use kNotFound,
it uses -1.

I think kNotFound is a string thing.

in addition to bulletproofing, can you assert with NS_ASSERTION(), this seems
like a bad scenario that we should catch.

Comment 18

[(not reading, please use [e-mail] instead)]

Comment on attachment 67926 [details] [diff] [review]
another place needing fixing.

sr=sspitzer, same comments as before, use -1 and please add an NS_ASSERTION().

Comment 19

[David :Bienvenu]

Attachment: check for negative index, add assertion

over AIM, Seth and I agreed on this approach.

Comment 20

[(not reading, please use [e-mail] instead)]

Comment on attachment 67930 [details] [diff] [review]
check for negative index, add assertion

sr=sspitzer

Comment 21

[David :Bienvenu]

Taking. I've made similar changes to the address book patch.

Comment 22

[Navin Gupta]

Comment on attachment 67926 [details] [diff] [review]
another place needing fixing.

r=naving

Comment 23

[Navin Gupta]

Comment on attachment 67930 [details] [diff] [review]
check for negative index, add assertion

r=naving

Comment 24

[David :Bienvenu]

fix for this crash checked in - don't know if there are others lurking in this
situation.

Comment 25

[[e-mail] (gone - use [e-mail] instead)]

I've searched Talkback up and down for numerous stack traces, and near as I can
tell, this is indeed fixed.  

Verified FIXED with build 2002-02-08-03, Windows 2000

Comment 26

[tabit]

Your patch fixed the crash-feature, but part of the bug still remains:

If I open some Emails, the viewer-Window stays empty. So I close that windows
(which used to cause the crashes before this bug was fixed) and reopen until I
can see the Email in the window.

My resume: You fixed the crash but the "empty viewer window"-issue still remains.

Comment 27

[David :Bienvenu]

please file a new bug on the mail window front end for that - this bug is about
the crasher, hence the summary and the keyword "crash".

Comment 28

[David :Bienvenu]

re-verifying.