55074 - Crash recursing in CountTotalMimeAttachments

Status: VERIFIED FIXED

(MailNews Core :: MIME, defect, P3)

Description

[Dan Mosedale (:dmosedale, :dmose)]

Linux trunk builds from this morning using SSL-IMAP.  Viewing a specific message
crashes every time.  Stack looks like this:

#0  0x41ec741a in CountTotalMimeAttachments (aObj=0x8929290)
    at /home/dmose/s/browser-main/mozilla/mailnews/mime/src/mimemoz2.cpp:208
	aObj = (MimeContainer *) 0x8929290
	i = 0
	rc = 0
#1  0x41ec7422 in CountTotalMimeAttachments (aObj=0x88d3300)
    at /home/dmose/s/browser-main/mozilla/mailnews/mime/src/mimemoz2.cpp:208
	aObj = (MimeContainer *) 0x88d3300
	i = 0
	rc = 0
#2  0x41ec7422 in CountTotalMimeAttachments (aObj=0x8929708)
    at /home/dmose/s/browser-main/mozilla/mailnews/mime/src/mimemoz2.cpp:208
	aObj = (MimeContainer *) 0x8929708
	i = 0
	rc = 0
#3  0x41ec7422 in CountTotalMimeAttachments (aObj=0x892bc18)
    at /home/dmose/s/browser-main/mozilla/mailnews/mime/src/mimemoz2.cpp:208
	aObj = (MimeContainer *) 0x892bc18
	i = 1
	rc = 1
#4  0x41ec7cb9 in MimeGetAttachmentList (tobj=0x8de9900, 
    aMessageURL=0x8de2f80
"imap://[e-mail]:143/fetch%3EUID%3E/INBOX%3E72672",
data=0xbffff380)
    at /home/dmose/s/browser-main/mozilla/mailnews/mime/src/mimemoz2.cpp:428
	obj = (MimeObject *) 0x892bc18
	cobj = (MimeContainer *) 0x892bc18
	n = 143834136
	isAlternativeOrRelated = 0
#5  0x41ec8f25 in mime_display_stream_complete (stream=0x8caab38)
    at /home/dmose/s/browser-main/mozilla/mailnews/mime/src/mimemoz2.cpp:899
	attachments = (nsMsgAttachmentData *) 0x0
	rv = 671335
	status = 671335
	abortNow = 0
	stream = (nsMIMESession *) 0xa3e67
	msd = (mime_stream_data *) 0x8de3d20
	obj = (MimeObject *) 0x8de9900
#6  0x41ed4ece in nsStreamConverter::OnStopRequest (this=0x8caae18, 
    aChannel=0x8dea8c0, ctxt=0x0, status=0, errorMsg=0x40137748)
    at
/home/dmose/s/browser-main/mozilla/mailnews/mime/src/nsStreamConverter.cpp:950
	tSession = (nsMIMESession *) 0x8caab38
#7  0x40a093cf in nsDocumentOpenInfo::OnStopRequest (this=0x8deaa08, 
    aChannel=0x8dea8c0, aCtxt=0x0, aStatus=0, errorMsg=0x40137748)
    at /home/dmose/s/browser-main/mozilla/uriloader/base/nsURILoader.cpp:266
	aChannel = (nsIChannel *) 0x8dea8c0
	rv = 0
#8  0x408581f5 in InterceptStreamListener::OnStopRequest (this=0x8deb9b8, 
    channel=0x8dea8c0, ctxt=0x0, aStatus=0, aStatusArg=0x40137748)
    at
/home/dmose/s/browser-main/mozilla/netwerk/cache/mgr/nsCachedNetData.cpp:1198
	this = (InterceptStreamListener *) 0x8deb9b8
#9  0x40818d1a in nsOnStopRequestEvent::HandleEvent (this=0x8db8b88)
    at
/home/dmose/s/browser-main/mozilla/netwerk/base/src/nsAsyncStreamListener.cpp:301
	this = (nsOnStopRequestEvent *) 0x8db8b88
	receiver = (nsIStreamObserver *) 0x8deb9b8
	status = 0
	rv = 1083160192
#10 0x40818176 in nsStreamListenerEvent::HandlePLEvent (aEvent=0x88598a8)
    at
/home/dmose/s/browser-main/mozilla/netwerk/base/src/nsAsyncStreamListener.cpp:97
#11 0x400f084e in PL_HandleEvent (self=0x88598a8)
    at /home/dmose/s/browser-main/mozilla/xpcom/threads/plevent.c:571
#12 0x400f06e9 in PL_ProcessPendingEvents (self=0x80af1d8)
    at /home/dmose/s/browser-main/mozilla/xpcom/threads/plevent.c:504
#13 0x400f24ae in nsEventQueueImpl::ProcessPendingEvents (this=0x80af1b0)
    at /home/dmose/s/browser-main/mozilla/xpcom/threads/nsEventQueue.cpp:356
#14 0x40a7683f in event_processor_callback (data=0x80af1b0, source=9, 
    condition=GDK_INPUT_READ)
    at /home/dmose/s/browser-main/mozilla/widget/src/gtk/nsAppShell.cpp:158
#15 0x40a764fd in our_gdk_io_invoke (source=0x8208ec0, condition=G_IO_IN, 
    data=0x8208eb0)
    at /home/dmose/s/browser-main/mozilla/widget/src/gtk/nsAppShell.cpp:58
#16 0x40c34aca in g_io_unix_dispatch () from /usr/lib/libglib-1.2.so.0
#17 0x40c36186 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#18 0x40c36751 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#19 0x40c368f1 in g_main_run () from /usr/lib/libglib-1.2.so.0
#20 0x40b5e5b9 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#21 0x40a77414 in nsAppShell::Run (this=0x8107528)
    at /home/dmose/s/browser-main/mozilla/widget/src/gtk/nsAppShell.cpp:335
#22 0x405b7a95 in nsAppShellService::Run (this=0x8113c30)
    at
/home/dmose/s/browser-main/mozilla/xpfe/appshell/src/nsAppShellService.cpp:407
#23 0x805278b in main1 (argc=1, argv=0xbffff774, nativeApp=0x0)
    at /home/dmose/s/browser-main/mozilla/xpfe/bootstrap/nsAppRunner.cpp:1004
#24 0x8052cf2 in main (argc=1, argv=0xbffff774)
    at /home/dmose/s/browser-main/mozilla/xpfe/bootstrap/nsAppRunner.cpp:1185
#25 0x402eb9cb in __libc_start_main (main=0x8052b9c <main>, argc=1, 
    argv=0xbffff774, init=0x804c370 <_init>, fini=0x805f4b4 <_fini>, 
    rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbffff76c)
    at ../sysdeps/generic/libc-start.c:92

Some other interesting info:

(gdb) frame 0
#0  0x41ec741a in CountTotalMimeAttachments (aObj=0x8929290)
    at /home/dmose/s/browser-main/mozilla/mailnews/mime/src/mimemoz2.cpp:208
208	    rc += CountTotalMimeAttachments((MimeContainer *)aObj->children[i]) + 1;
(gdb) print *aObj
$11 = {object = {clazz = 0x746e6f43, headers = 0x2d746e65, 
    content_type = 0x65707954 <Address 0x65707954 out of bounds>, 
    encoding = 0x6574203a <Address 0x6574203a out of bounds>, 
    parent = 0x702f7478, options = 0x6e69616c, closed_p = 1852785418, 
    parsed_p = 1953391988, output_p = 977553709, 
    showAttachmentIcon = 808598537, 
    ibuffer = 0x30313030 <Address 0x30313030 out of bounds>, 
    obuffer = 0x32313230 <Address 0x32313230 out of bounds>, 
    ibuffer_size = 959591984, obuffer_size = 1143818542, 
    ibuffer_fp = 1952803136, obuffer_fp = 1919888998}, children = 0xa3e67, 
  nchildren = 41}
(gdb) print aObj->children[0]
Cannot access memory at address 0xa3e67
(gdb) up
#1  0x41ec7422 in CountTotalMimeAttachments (aObj=0x88d3300)
    at /home/dmose/s/browser-main/mozilla/mailnews/mime/src/mimemoz2.cpp:208
208	    rc += CountTotalMimeAttachments((MimeContainer *)aObj->children[i]) + 1;
(gdb) print *aObj 
$12 = {object = {clazz = 0x41efddc0, headers = 0x892be68, 
    content_type = 0x89b1ca8 "Message/External-body", encoding = 0x0, 
    parent = 0x8929708, options = 0x8de97b0, closed_p = 1, parsed_p = 1, 
    output_p = 1, showAttachmentIcon = 0, ibuffer = 0x0, obuffer = 0x0, 
    ibuffer_size = 0, obuffer_size = 0, ibuffer_fp = 0, obuffer_fp = 0}, 
  children = 0x891a850, nchildren = 145398080}

I'll also attach the message itself.  Perhaps CountTotalMimeAttachments() needs
a special case so it doesn't attempt to keep recursing with content-type
message/external-body?

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: message that caused the crash

Comment 2

[rhp (gone)]

This message does kick off that crash. I'll investigate and see if this is easy 
or hard to fix.

- rhp

Comment 3

[Kathleen :Brade]

nominate for rtm
I see this crash trying to view a message with a Mac debug mozilla build from 
today.  My husband sees this crash with nsbeta3 on Windows.  Setting to All 
Platform/OS.

Comment 4

[rhp (gone)]

Just some more info:
This is actually a problem rendering this message. SSL-IMAP has nothing to do 
with it.

- rhp

Comment 5

[scottputterman]

Adding rtm need info. This is showing up as a top crash.

Comment 6

[scottputterman]

This is actually not showing up as a top crash in PR3 data yet, but I just saw a 
report from PR2 which has a lot more data and this was the 19th on the list with 
92 crashes.

Comment 7

[scottputterman]

Rich, any ideas on why this is happening?

Comment 8

[rhp (gone)]

I've been working on this for a while and tried Purify today to no avail. It is 
a problem with multipart alternative mail messgages that are part of a 
multipart mixed email (i think).

I am digging away and hope to have something later tonight/tomorrow morning.

Comment 9

[rhp (gone)]

I think I have a fix for this now. I will attach the patch.

- rhp

Comment 10

[rhp (gone)]

Attachment: Here is a possible fix

Comment 11

[scottputterman]

putting rtm need info back on.  We need a reviewer and a super reviewer before
we can proceed.

Comment 12

[rhp (gone)]

Ok...got the first review: r: bienvenu

Thanks David

Comment 13

[Scott MacGregor]

sr=mscott

Comment 14

[pmock]

Rich,

I can't reproduce the crash using the 10/11 branch win32, linux, and macos 
builds. I enabled the mail option "use ssl..." and loaded the test message.
On win32, it refuses my connection to server nsmail-2
On linux, it loads just the header - similar behavior to Communicator 4.7x
On Mac, it loads just the header - similar behavior to Communicator 4.7x.

My question, is this just a debug problem?  If not, how do I reproduce and 
verify this bug.  
Thanks.
/Peter

Comment 15

[rhp (gone)]

This is actually pretty reproducable for me. Ignore the SSL stuff. Doesn't have 
anything to do with it. I just put the test message in a local mail box and 
bang. 

The fix will address this if I can permission.

- rhp

Comment 16

[scottputterman]

marking rtm+.  This crash is also showing up on the official PR3 release top
crashes.

Comment 17

[selmer (gone)]

looking for fewer casts in the patch, come back when the minor updates are ready 
and re-reviewed.

Comment 18

[rhp (gone)]

I just got done talking to mscott....the casts aren't there to hide 
warnings...they are there to allow it to compile and run using jwz's homegrown 
object system.

- rhp

Comment 19

[rhp (gone)]

Attachment: Second patch without the one cast

Comment 20

[Scott MacGregor]

rtm++ per my instructions from pdt.
sr=mscott with the cast removed.

Comment 21

[rhp (gone)]

Fixed checked in to tree and branch.

- rhp

Comment 22

[esther]

Using builds 2000-10-19 branch on win98, mac and linux and the attached message
that caused a crash, I do not crash opening this message.  Verified

Comment 23

[rhp (gone)]

*** Bug 57452 has been marked as a duplicate of this bug. ***