156572 - crash in nsImapMailCopyState::~nsImapMailCopyState()

Status: RESOLVED WORKSFORME

(MailNews Core :: Networking: IMAP, defect)

Description

[Dawn Endico]

I switched between an imap folder and a local folder and crashed, 
resulting in the following stack. I searched for other crashes with
"nsSupportsArray::Clear" stack signature and got a ton of hits. Most
of the reports that had comments indicated that the crash had something
to do with mail but not all of the mail crashes seemed to be related
to mine. Here's a list of some that had nsImapMailCopyState() in the
stack. Some of these indicate that the person was copying a bunch of
messages from one folder to another.

(fwiw, i don't recall ever crashing when copying a lot of mails between
imap folders but i have had problems. iirc, mozilla stalls and i have
to retry with smaller batches)


http://climate.netscape.com/reports/incidenttemplate.cfm?bbid=7412302
http://climate.netscape.com/reports/incidenttemplate.cfm?bbid=7988327
http://climate.netscape.com/reports/incidenttemplate.cfm?bbid=7937297
http://climate.netscape.com/reports/incidenttemplate.cfm?bbid=8120752
http://climate.netscape.com/reports/incidenttemplate.cfm?bbid=7724114

marking platform/os as all/all since the above stacks are from win32.


Incident ID 8153360
Stack Signature nsSupportsArray::Clear() f3a56b6e
Email Address [e-mail]
Product ID Gecko1.0
Build ID 2002052918
Trigger Time 2002-07-09 15:21:36
Platform LinuxIntel
Operating System Linux 2.4.7-10
Module libxpcom.so
URL visited
User Comments switched between imap and local folders in mail.
Trigger Reason SIGSEGV: Segmentation Fault: (signal 11)
Source File Name
Trigger Line No.
Stack Trace
nsSupportsArray::Clear()
nsSupportsArray::DeleteArray()
nsSupportsArray::~nsSupportsArray()
nsSupportsArray::Release()
nsCOMPtr_base::~nsCOMPtr_base()
nsImapMailCopyState::~nsImapMailCopyState()
nsImapMailCopyState::Release()
nsCOMPtr_base::assign_with_AddRef()
nsImapMailFolder::ReleaseObject()
XPTC_InvokeByIndex()
EventHandler()
PL_HandleEvent()
PL_ProcessPendingEvents()
nsEventQueueImpl::ProcessPendingEvents()
event_processor_callback()
our_gdk_io_invoke()
libglib-1.2.so.0 + 0xff9e (0x40395f9e)
libglib-1.2.so.0 + 0x11773 (0x40397773)
libglib-1.2.so.0 + 0x11d39 (0x40397d39)
libglib-1.2.so.0 + 0x11eec (0x40397eec)
libgtk-1.2.so.0 + 0x94333 (0x402b3333)
nsAppShell::Run()
nsAppShellService::Run()
main1()
main()
libc.so.6 + 0x1c507 (0x404de507)

Comment 1

[Karen Huang]

Is this crash occurring on trunk build, branch build or both?

Comment 2

[Brant Gurganus]

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.

Comment 3

[Wayne Mery (:wsmwk)]

closing WFM based on no crashes on talkback for nsImapMailCopyState::~nsImapMailCopyState

(+never been any responses from reporter)