Closed Bug 346243 Opened 18 years ago Closed 18 years ago

Increased Rlk (leak) on balsa after 2006-07-27

Categories

(Core :: General, defect)

1.8 Branch
x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: ispiked, Assigned: vlad)

Details

(Keywords: memory-leak)

Attachments

(1 file)

Rlk on balsa went from 860 bytes to 1016 bytes this afternoon.

Check-ins: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-07-27+15%3A40&maxdate=2006-07-27+18%3A39&cvsroot=%2Fcvsroot

--NEW-LEAKS-----------------------------------leaks------leaks%
nsDebugImpl                                      12          -
nsVoidArray                                     152    1800.00%

The nsDebugImpl leak is probably bogus. I'm pretty sure we randomly leak those.
Attached patch potential fixSplinter Review
This might be me -- I checked in (unintentionally) a change in how a nsMutableArray instance is constructed.  However, I don't see why this would have done it -- mFunctions is nsCOMPtr<nsIMutableArray> and hasn't changed, so both these calls should be equivalent (except that the old one depends on NS_NewArray being available instead of constructing by contractid).  Does nsArray even use nsVoidArray internally?
This was fixed between 2006-08-02 11:36 and 2006-08-02 19:06 . Looks like this had something to do with the patch for bug 346233/bug 321299.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-08-02+11%3A36&maxdate=2006-08-02+19%3A06&cvsroot=%2Fcvsroot
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Assignee: nobody → vladimir
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: