opening email crashes mozilla

VERIFIED FIXED

Status

--
critical
VERIFIED FIXED
17 years ago
14 years ago

People

(Reporter: mozzilla, Assigned: Bienvenu)

Tracking

({crash})

Trunk
x86
Windows 2000
crash

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

17 years ago
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

17 years ago
could be related to bug 111237

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

Comment 2

17 years ago
Dear sebastian@rolux.org,

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
(Reporter)

Comment 3

17 years ago
and again: TB38657770M

cold be related to bug 108425 !!!
(Reporter)

Comment 4

17 years ago
another one: TB38703965M

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

Updated

17 years ago
Severity: normal → critical

Comment 5

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

Stephen: can you pull TB38657770M
Stack Signature  nsProxyEventObject::GetInterfaceInfo 4b3f958f
Trigger Time 2001-12-05 22:00:51
Email Address mozzilla@afrika.net
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] 
(Reporter)

Comment 7

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

Comment 8

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

regards

tabit

Updated

17 years ago
Keywords: crash
(Reporter)

Comment 9

17 years ago
Possibly the missing link between bug 112834 and bug 111703:

TB1134401X
(Reporter)

Comment 10

17 years ago
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

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

Comment 12

17 years ago
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]
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 13

17 years ago
TB2059831M (on build nightly 18012002)
(Assignee)

Comment 14

17 years ago
Created attachment 67925 [details] [diff] [review]
proposed bulletproofing fix

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

Comment 15

17 years ago
Seth and Navin, can you review? Also, Seth, nsAddrBookSession needs the same
fix, which I will attach.
(Assignee)

Comment 16

17 years ago
Created attachment 67926 [details] [diff] [review]
another place needing fixing.
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.
Attachment #67925 - Flags: superreview+
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().
Attachment #67926 - Flags: superreview+
(Assignee)

Comment 19

17 years ago
Created attachment 67930 [details] [diff] [review]
check for negative index, add assertion

over AIM, Seth and I agreed on this approach.
Attachment #67925 - Attachment is obsolete: true
Comment on attachment 67930 [details] [diff] [review]
check for negative index, add assertion

sr=sspitzer
(Assignee)

Comment 21

17 years ago
Taking. I've made similar changes to the address book patch.
Assignee: sspitzer → bienvenu

Comment 22

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

r=naving
Attachment #67926 - Flags: review+

Comment 23

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

r=naving
Attachment #67930 - Flags: review+
(Assignee)

Comment 24

17 years ago
fix for this crash checked in - don't know if there are others lurking in this
situation.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
QA Contact: esther → stephend
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
Status: RESOLVED → VERIFIED
(Reporter)

Comment 26

17 years ago
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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 27

17 years ago
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".
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED
(Assignee)

Comment 28

17 years ago
re-verifying.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.