Closed Bug 66867 Opened 24 years ago Closed 23 years ago

nsMsgNewsFolder::SetCachedNewsrcLine leaks

Categories

(MailNews Core :: Networking: NNTP, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.2

People

(Reporter: dbaron, Assigned: hwaara)

References

Details

(Keywords: memory-leak)

Attachments

(6 files)

When starting mozilla, starting mailnews, reading a news message, and exiting,
the Boehm GC showed the call to nsCRT::strdup as being leaked:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/mailnews/news/src/nsNewsFolder.cpp&rev=1.156&mark=1589#1579

I assume the leak was because nsMsgNewsFolder::SetCachedNewsrcLine was called
multiple times.  I think you should do one of:
 * fail silently if it's called multiple times, without a strdup
 * assert if it's called multiple times, and then figure out why
 * free the old value if it's non-null
Following dbaron's third step, this should fix the leak.  It might not be the
correct way to fix it, but it definatly gets rid of the leak.

When I load mailnews, 5 strings are leaked.
Ignore the first patch.  Can someone take a look at this?
For memory allocated with nsCRT::strdup, you should free with nsCRT::free.  I'd
also prefer the style (although the module owner of this code may prefer braces):

if (mCcahedNewsrcLine)
  nsCRT::free(mCachedNewsrcLine)

(There's no need to set to null because you're assigning again right below, and
the "nsnull !=" is unnecessary.)
Attached patch new patchSplinter Review
Thank you David for your comments.  The above patch addresses your comments.

In other parts of the file, delete [] is used instead of nsCRT::free, so maybe I
should just leave it at that to keep it consistent.  I'll attach one using
delete[] so the module owner could choose which one they prefer.
So, choose between patch #24319 and #24320.
Comments on the existing uses of delete[] in that file:

UpdateSummaryFromNNTPInfo - incorrect.  Memory was allocated by nsMemory::Alloc
and should thus be freed with nsMemory::Free.  This should probably be
documented in nsMsgKeySet.h

HandleNewsrcLine - This is correct because nsMsgGroupRecord::GetFullName
allocates using new[].
I guess this patch needs r= and sr=
Keywords: patch, review
OS: Linux → All
actually, r=hwaara on latest patch. if HandleNewsrcLine was allocated with new
[] it should be deallocated with delete [].
Keywords: reviewapproval
QA Contact: esther → stephend
bienvenu, can you sr= this patch?  I can update it to the trunk and check it in
if needed.
*** Bug 82524 has been marked as a duplicate of this bug. ***
I find it ridicolous that this patch after merely 4 months still hasn't got sr=.
It's just a one-liner...
Taking to drive the patch in. No one seems to care.

Now, to hunt down someone for sr=.
Assignee: sspitzer → hwaara
Target Milestone: --- → mozilla0.9.2
give me a chance after 0.9.1 and I'll review it.
Seth, can you please sr= this little fix?
mCachedNewsrcLine is always allocated with nsCRT::strdup(), so you should use 
nsCRT::free to free it (although the dtor uses PR_FREEIF()).

Even with your patch, the if (mCachedNewsrcLine) is redundant; |delete| and |
delete[]| are guaranteed safe with null pointers.
Attached patch new fixSplinter Review
sr=blizzard
a= asa@mozilla.org for checkin to the trunk.
(on behalf of drivers)
Blocks: 83989
fix checked in yesterday.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
supplimental patch.

thanks to sfraser for pointing out the dtor problem.



Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Seth, can you explain the patch please.
1) the CRTFREEFIF will prevent a crash if mCachedNewsrcLine is null.

2) as sfmr wrote:  "mCachedNewsrcLine is always allocated with nsCRT::strdup(), 
so you should use nsCRT::free to free it (although the dtor uses PR_FREEIF())."

smfr pointed out that we had a mis matched memory free in the dtor, and this 
patch fixes that.
Sounds like the right thing to do. r=hwaara
a=dbaron for trunk checkin (on behalf of drivers)
fixed again.
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
sending leak/opt bugs over to my other bugzilla account
QA Contact: stephend → stephen.donner
Verified FIXED, this didn't show up in my Purify logs for news lately.
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: