If I try and view a mail message that contains 20 attachments or more then a crash (seg fault) occurs. Originally I got this because Lotus Mail [Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)] has a tendancy to take normal mail messages and turn them into a mixture of text/plain; charset=iso-8859-1 and text/plain; charset=us-ascii attachments. One mail message I received had been broken into 42 attachments! It is possible to repeat the problem by attaching twenty small text files to a mail message, sending it to yourself and then trying to view it with 'view attachments inline' set.(I redirected the output of ls into a file and made 19 copies of the file). Build Id: 2000041212 Netscape Mail 4.7 does not have this problem.
Did you submit a talkback report on this crash?
My nightly build isn't creating talkbacks - I'm not sure if that is because build id 2000041212 doesn't have them enabled, or when the browser seg faults it doesn't get a chance to create a talkback. I can forward a sample mail message that will cause the crash, e-mail me with an address.
Let us try it here first. If we can't get a msg with 19 attachments or more to crash, we'll email you.
Reassign to mscott, maybe it's a problem for rhp or jefft.
Problem is reproducible on all platforms using the following builds: win32 commercial seamonkey build 00041909-m16 linux commercial seamonkdy build 00041910-m16 macos commercial seamonkey build 00041804-m16 It crashes under IMAP and POP. I notice that the app crashes even at 19 attachments. Sometimes, I can load the message but it eventually crashes after closing and re-openning the mail message.
Putting on [nsbeta2+] radar.
fyi, Problem is reproducible on today 2000-04-28-09-m16 win32, linux, and mac os platforms. It crashes while downloading message.
Hey peter, can you send me the test message that will trigger the crash for me. Saves me the trouble of building up a message with 19 attachments. Thanks!
I think this belongs to rhp. We are crashing here: NotifyEmittersOfAttachmentList(MimeDisplayOptions * 0x0337f0b0, nsMsgAttachmentData * 0x03dee5d0) line 481 + 17 bytes mime_display_stream_complete(_nsMIMESession * 0x0337ce80) line 775 + 16 bytes nsStreamConverter::OnStopRequest(nsStreamConverter * const 0x0337fb40, nsIChannel * 0x03ec1640, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x00000000) line 821 + 13 bytes nsDocumentOpenInfo::OnStopRequest(nsDocumentOpenInfo * const 0x03ec1900, nsIChannel * 0x03ec1640, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x00000000) line 204 Inside of NotifyEmittersOfAttachmentList, we are given a valid nsMsgAttachmentData object. However, inside that code, we assign a variable "tmp" to it. Then we get in a loop where we are incrementing tmp using tmp++. Eventually we get a bogus ptr to tmp.
Will investigate. - rhp
Difference in sizeof()'s for structures. - rhp
I've just verified this fix with build id 2000051820 on Linux x86, using the original message that identified this problem, and I'm stoked to say it displayed correctly.
Verified as fixed on win32, macos, and linux using the following builds: win32 commercial seamonkey build 00052310-m16 installed on P200, Winnt 4.0 SP6 macos commercial seamonkey build 00052308-m16 installed on G3/400, MacOS 9.04 linux commercial seamonkey build 00052120-m16 installed on P200, RedHat 6.1