This report came from Jean-Francois: The short summary is that when you send a message and separate multiple senders using a ';' (which is illegal, it should be a comma, but you could enter it by accident) we corrupt memory and crash unpleasantly. I don't believe this is a common thing. So this isn't a critical crasher that needs fixed for M7. But any crash is bad and we should figure why we can't handle the ';'.... When I send a message to two recipient separated by a ";" instance of a ",", I get the memory overwritten. I don't know if the origin of the problem is in mime or it's a smtp matter: here is the trace of the problem. First I get an Assertion message cause by msg_quote_phrase_or_addr(char*, int, int)+00618: User break at 16247064 dprintf(const char*, ...)+00098 Assertion: "" (new_length == (out - orig_out)) at file nsMsgHeaderParser.cpp, line 943 Return addresses on the stack Stack Addr Frame Addr ISA Caller [I have removed the begining] 063CA5DC 063CA5D4 PPC 1790EDE8 nsMsgComposeAndSend::CreateAndSendMessage(nsIMsgCom pFields*, int, int, nsMsgDeliverMode, const char*, const char*, unsigned int, const nsMsgAtta chmentData*, const nsMsgAttachedFile*, void*, unsigned int (*)(unsigned int, void*, nsFileSpe c*), vo+000AC 063CA5A4 68K 063CAA12 063CA54C 063CA544 PPC 1790C588 nsMsgComposeAndSend::Init(nsMsgCompFields*, nsFileS pec*, int, int, nsMsgDeliverMode, const char*, const char*, unsigned int, const nsMsgAttachme ntData*, const nsMsgAttachedFile*, nsMsgSendPart*, void*)+002C8 063CA544 68K 063CA5D2 063CA4FC PPC 1660DA80 PL_strdup+00030 063CA4DC 063CA4D4 PPC 17920C2C nsMsgMIMESetConformToStandard+000DC 063CA4CC 063CA4C4 PPC 1622AF7C PREF_GetBoolPref+00020 063CA4BC 063CA4B4 PPC 1790BAFC nsMsgComposeAndSend::HackAttachments(const nsMsgAtt achmentData*, const nsMsgAttachedFile*)+00D80 063CA46C PPC 16416D18 nsLargeHeapAllocator::AllocatorMakeBlock(unsigned l ong)+00038 063CA40C 68K 1624BAEA nsServiceManagerImpl::ReleaseService(const nsID&, n sISupports*, nsIShutdownListener*)+00132 063CA3CC 063CA3C4 PPC 162468F4 nsHashtable::Get(nsHashKey*)+00058 063CA3BC 063CA3B4 PPC 166273E4 PR_CExitMonitor+00074 063CA3B4 68K 063CA3F2 063CA31C PPC 1660BF28 PL_HashTableRawLookup+0005C 063CA27C 063CA274 PPC 1790A368 nsMsgComposeAndSend::GatherMimeAttachments()+020D8 063CA22C 68K 1628A822 nsOutputFileStream::~nsOutputFileStream()+000F6 063CA20C 063CA204 PPC 1790C9C0 nsMsgComposeAndSend::DeliverMessage()+001E8 063CA18C 063CA184 PPC 16414474 free+0006C 063CA0EC 063CA0E4 PPC FFD622F4 PBCloseSync+00028 063CA0CC 063CA0C4 PPC 1790CE5C nsMsgComposeAndSend::DeliverFileAsMail()+00438 063CA08C PPC 16275F74 nsString::nsString(const char*, eCharSize, nsIMemor yAgent*)+0004C 063CA04A 68K 0010FFFC 063C9FFC 063C9FF4 PPC 17915F54 nsSmtpService::SendMailMessage(const nsFilePath&, c onst nsString&, nsIUrlListener*, nsIURL**)+0021C 063C9FC2 68K 00000596 063C9FBA 68K 00000596 063C9F8C 063C9F84 PPC 17916418 NS_MsgLoadMailtoUrl(nsIURL*, nsISupports*)+00120 063C9F74 68K 063C9FC6 063C9EFC 063C9EF4 PPC 17915250 nsSmtpProtocol::LoadUrl(nsIURL*, nsISupports*)+001B C 063C9EBC 063C9EB4 PPC 17918774 nsSmtpUrl::GetAllRecipients(char**)+00034 063C9E9C 063C9E94 PPC 16C86CC4 nsMsgHeaderParser::RemoveDuplicateAddresses(const c har*, const char*, const char*, int, char**)+000BC 063C9E4C PPC 16C69790 MIME_ConvertString+00048 063C9DEC 063C9DE4 PPC 16C89624 msg_remove_duplicate_addresses(const char*, const c har*, int)+000A8 063C9DC2 68K 00000596 063C9D4C PPC 16413278 operator new(unsigned long)+00018 063C9D2C 063C9D24 PPC 162762A0 nsString::~nsString()+00030 063C9CEC PPC 1626E324 nsStr::Destroy(nsStr&, nsIMemoryAgent*)+00060 063C9CCC 063C9CC4 PPC 16C882A4 msg_parse_Header_addresses(const char*, char**, cha r**, int, int, int)+010B8 063C9C3C 063C9C34 PPC 16C88B58 msg_quote_phrase_or_addr(char*, int, int)+00618 063C9BFC 063C9BF4 PPC 1624731C nsDebug::Assertion(const char*, const char*, const char*, int)+00040 063C9BDC 063C9BD4 PPC 16414D8C nsFixedSizeAllocator::AllocatorMakeBlock(unsigned l ong)+000AC 063C9BAC 063C9BA4 PPC 16414380 malloc+00088 063C9B92 68K 0001FFFE 063C9B70 68K 0614BA56 063C9B6C PPC 1626E570 nsStr::GrowCapacity(nsStr&, unsigned int, nsIMemory Agent*)+000A0 063C9B4C 063C9B44 PPC 16414D8C nsFixedSizeAllocator::AllocatorMakeBlock(unsigned l ong)+000AC 063C9AD0 063C9ACC 68K 0614BA56 063C9ABC 063C9AB4 PPC 16247018 dprintf(const char*, ...)+0004C then later, the memory has been overwritten. This is detected only during the free... User break at 16414EAC nsFixedSizeAllocator::AllocatorFreeBlock(void*)+0006C Bad block trailer Calling chain using A6/R1 links Back chain ISA Caller 2C00084A PPC 1629C358 XPTC_InvokeByIndex+0012C 063CAC54 PPC 179284DC nsMsgCompose::SendMsg(int, const unsigned short*)+006A8 063CA9A4 PPC 17929258 nsMsgCompose::SendMsgEx(int, const unsigned short*, const unsign ed short*, const unsigned short*, const unsigned short*, const unsigned short*, const unsigne d short*, const unsigned short*)+00C88 063CA634 PPC 1790EDE8 nsMsgComposeAndSend::CreateAndSendMessage(nsIMsgCompFields*, int , int, nsMsgDeliverMode, const char*, const char*, unsigned int, const nsMsgAttachmentData*, const nsMsgAttachedFile*, void*, unsigned int (*)(unsigned int, void*, nsFileSpec*), vo+000AC 063CA5D4 PPC 1790C588 nsMsgComposeAndSend::Init(nsMsgCompFields*, nsFileSpec*, int, in t, nsMsgDeliverMode, const char*, const char*, unsigned int, const nsMsgAttachmentData*, cons t nsMsgAttachedFile*, nsMsgSendPart*, void*)+002C8 063CA544 PPC 1790BAFC nsMsgComposeAndSend::HackAttachments(const nsMsgAttachmentData*, const nsMsgAttachedFile*)+00D80 063CA4B4 PPC 1790A368 nsMsgComposeAndSend::GatherMimeAttachments()+020D8 063CA274 PPC 1790C9C0 nsMsgComposeAndSend::DeliverMessage()+001E8 063CA204 PPC 1790CE5C nsMsgComposeAndSend::DeliverFileAsMail()+00438 063CA0C4 PPC 17915F54 nsSmtpService::SendMailMessage(const nsFilePath&, const nsString &, nsIUrlListener*, nsIURL**)+0021C 063C9FF4 PPC 17916418 NS_MsgLoadMailtoUrl(nsIURL*, nsISupports*)+00120 063C9F84 PPC 17915250 nsSmtpProtocol::LoadUrl(nsIURL*, nsISupports*)+001BC 063C9EF4 PPC 16C86CC4 nsMsgHeaderParser::RemoveDuplicateAddresses(const char*, const c har*, const char*, int, char**)+000BC 063C9E94 PPC 16C89624 msg_remove_duplicate_addresses(const char*, const char*, int)+00 0A8 063C9DE4 PPC 16C882A4 msg_parse_Header_addresses(const char*, char**, char**, int, int , int)+010B8 063C9CC4 PPC 16C88B80 msg_quote_phrase_or_addr(char*, int, int)+00640 063C9C34 PPC 16623470 PR_Free+00014 063C9BF4 PPC 16414474 free+0006C

Accepting, setting TFV to M8.

Currently we are not crashing in Mac in debug mode but it might be possible that we do with the release build as we don't have some extra pading between each memory block allocated.

It may be that in the old world, the FE would never let this happen and therefore we never saw the bug...just a guess. - rhp

<Will add to release notes for M7>

Do you mean recipients instead of senders in your summary and description? There can only be one sender.

Yes I do mean recipients =). Thanks...

this is a very very rare case since it requires the user to make a 'typo' using ';'...prioritizing my bug list and pushing this after m8....

This would be very nice to fix for PR1. While we could release note this, it would be better to ship without known crashers. I added a note the the Status Whiteboard to reflect the fact that this would be good to fix for PR1.

Triage to M12

(target milestone is M11 or M12 - add to mail beta tracking bug)

I checked in the fix for this. There was some old crufty mime code that wasn't allocating enough bytes for a string and then walking past the end of the string. An easy test case: Address a messge to foo@netscapecom;foo@netscape.com we would have corrupted memory and debug builds would have generated an assertion stating such. Now, with the fix you won't see the warning complaining about corrupted memory. Note: of course this msg will bounce because ';' is not a valid delimeter for email addresses. your supposed to use ',' but that isn't a bug it is by design. So when the message is sent you'll get it bounced back to you.

Using builds 2000101211m13 on win98, 2000011212m13 on linux and 2000011208 on Mac this is fixed because I don't crash and I do get a bounce back, but should this be the bounce back: "The original message was received at Thu, 13 Jan 2000 09:12:50 -0800 (PST) from dredd.mcom.com [205.217.237.54] ----- The following addresses had permanent fatal errors ----- <"\"\"foo\"@netscapecom;foo@netscape.com"@netscape.com> ----- Transcript of session follows ----- 550 <"\"\"foo\"@netscapecom;foo@netscape.com"@netscape.com>... Host unknown (Name server: netscapecom;foo: host not found) I will verify this as stated, but mscott let me know if the bounce back message is correct. Notice it doesnt' correctly state what I entered in the To: field and when viewing the offensive header in the bounce back message it shows that I enterend "foo\"@netscapecom;foo@netscape.com in the To: field.

Yes, this bounce back message is correct. It's exactly what you wrote except it has been quoted in order to send it to the server. i.e. there are two '@' signs in the email address you typed in. One of them has to be quoted. And that's why you have the quoting characters in front of it. Thanks for verifying!