Closed Bug 111291 Opened 24 years ago Closed 24 years ago

MLK: leaking many char* in nsMsgAttachmentHandler

Categories

(MailNews Core :: Composition, defect)

x86
Windows NT
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: naving, Assigned: naving)

References

Details

Attachments

(1 file, 1 obsolete file)

From purify [W] MLK: Memory leak of 5 bytes from 1 block allocated in PL_strdup Distribution of leaked blocks Allocation location malloc [dbgheap.c:129] PL_strdup [strdup.c:46] nsMsgAttachmentHandler::PickEncoding(char const*,nsIMsgSend *) [nsMsgAttachmentHandler.cpp:319] } else { PR_FREEIF(m_encoding); => m_encoding = PL_strdup (ENCODING_7BIT); } } nsMsgComposeAndSend::GatherMimeAttachments(void) [nsMsgSend.cpp:781] nsMsgAttachmentHandler::UrlExit(UINT,WORD const*) [nsMsgAttachmentHandler.cpp:1175] FetcherURLDoneCallback [nsMsgAttachmentHandler.cpp:469] nsURLFetcher::OnStopRequest(nsIRequest *,nsISupports *,UINT) [nsURLFetcher.cpp:322] nsDocumentOpenInfo::OnStopRequest(nsIRequest *,nsISupports *,UINT) [nsURILoader.cpp:252] nsFileChannel::OnStopRequest(nsIRequest *,nsISupports *,UINT) [nsFileChannel.cpp:481] nsOnStopRequestEvent::HandleEvent(void) [nsRequestObserverProxy.cpp:176] [W] MLK: Memory leak of 11 bytes from 1 block allocated in PL_strdup Distribution of leaked blocks Allocation location malloc [dbgheap.c:129] PL_strdup [strdup.c:46] nsMsgComposeAndSend::GatherMimeAttachments(void) [nsMsgSend.cpp:647] PR_FREEIF(m_plaintext->m_charset); m_plaintext->m_charset = PL_strdup(mCompFields->GetCharacterSet()); PR_FREEIF(m_plaintext->m_desired_type); => m_plaintext->m_desired_type = PL_strdup(TEXT_PLAIN); m_attachment_pending_count ++; status = m_plaintext->SnarfAttachment(mCompFields); if (status < 0) nsMsgComposeAndSend::HackAttachments(nsMsgAttachmentData const*,nsMsgAttachedFile const*) [nsMsgSend.cpp:2586] nsMsgComposeAndSend::Init(nsIMsgIdentity *,nsMsgCompFields *,nsFileSpec *,int,int,int,nsIMsgDBHdr *,char const*,char const*,UINT,nsMsgAttachmentData const*,nsMsgAttachedFile const*,char const*) [nsMsgSend.cpp:2949] nsMsgComposeAndSend::CreateAndSendMessage(nsIEditorShell *,nsIMsgIdentity *,nsIMsgCompFields *,int,int,int,nsIMsgDBHdr *,char const*,char const*,UINT,nsMsgAttachmentData const*,nsMsgAttachedFile const*,void *,nsIDOMWindowInternal *,nsIMsgProgress *,nsIMs [nsMsgSend.cpp:3699] nsMsgCompose::_SendMsg(int,nsIMsgIdentity *,int) [nsMsgCompose.cpp:874] nsMsgCompose::SendMsg(int,nsIMsgIdentity *,nsIMsgProgress *) [nsMsgCompose.cpp:980] XPTC_InvokeByIndex [xptcinvoke.cpp:152] XPCWrappedNative::CallMethod(XPCCallContext&,CallMode::XPCWrappedNative) [xpcwrappednative.cpp:2009] [W] MLK: Memory leak of 11 bytes from 1 block allocated in PL_strdup Distribution of leaked blocks Allocation location malloc [dbgheap.c:129] PL_strdup [strdup.c:46] nsMsgComposeAndSend::GatherMimeAttachments(void) [nsMsgSend.cpp:645] PR_FREEIF(m_plaintext->m_type); m_plaintext->m_type = PL_strdup(TEXT_HTML); PR_FREEIF(m_plaintext->m_charset); => m_plaintext->m_charset = PL_strdup(mCompFields->GetCharacterSet()); PR_FREEIF(m_plaintext->m_desired_type); m_plaintext->m_desired_type = PL_strdup(TEXT_PLAIN); m_attachment_pending_count ++; nsMsgComposeAndSend::HackAttachments(nsMsgAttachmentData const*,nsMsgAttachedFile const*) [nsMsgSend.cpp:2586] // If no attachments - finish now (this will call the done_callback). if (needToCallGatherMimeAttachments) => return GatherMimeAttachments(); return 0; } nsMsgComposeAndSend::Init(nsIMsgIdentity *,nsMsgCompFields *,nsFileSpec *,int,int,int,nsIMsgDBHdr *,char const*,char const*,UINT,nsMsgAttachmentData const*,nsMsgAttachedFile const*,char const*) [nsMsgSend.cpp:2949] nsMsgComposeAndSend::CreateAndSendMessage(nsIEditorShell *,nsIMsgIdentity *,nsIMsgCompFields *,int,int,int,nsIMsgDBHdr *,char const*,char const*,UINT,nsMsgAttachmentData const*,nsMsgAttachedFile const*,void *,nsIDOMWindowInternal *,nsIMsgProgress *,nsIMs [nsMsgSend.cpp:3699] nsMsgCompose::_SendMsg(int,nsIMsgIdentity *,int) [nsMsgCompose.cpp:874] nsMsgCompose::SendMsg(int,nsIMsgIdentity *,nsIMsgProgress *) [nsMsgCompose.cpp:980] XPTC_InvokeByIndex [xptcinvoke.cpp:152] XPCWrappedNative::CallMethod(XPCCallContext&,CallMode::XPCWrappedNative) [xpcwrappednative.cpp:2009]
QA Contact: sheelar → stephend
Summary: MLK: leaking char* in nsMsgAttachmentHandler → MLK: leaking many char* in nsMsgAttachmentHandler
Attached patch proposed fix (obsolete) — Splinter Review
all the char* should be destroyed in the destructor.
cc ducarroz for review I have tested it w/ attachment and plain/text html message. I don't see the attachment handler itself leaking so this will fix it.
Status: NEW → ASSIGNED
Comment on attachment 58769 [details] [diff] [review] proposed fix R=ducarroz
Attachment #58769 - Flags: review+
Attached patch proposed fixSplinter Review
I have found two more char*
Attachment #58769 - Attachment is obsolete: true
cc bienvenu for sr.
Comment on attachment 58775 [details] [diff] [review] proposed fix looks good - it also looks like it's the same leak as the one we were recently discussing.
Attachment #58775 - Flags: superreview+
Stephen, yes, I think so. I think bug 111083 might also be a dup of this bug.
*** Bug 99112 has been marked as a duplicate of this bug. ***
*** Bug 111083 has been marked as a duplicate of this bug. ***
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
*** Bug 99177 has been marked as a duplicate of this bug. ***
verified fixed.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: