396299 - Linux fx-linux-tbox Dep Nightly trace_malloc_leaks jump

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[Steve England [:stevee]]

trace_malloc_leaks on Linux fx-linux-tbox Dep Nightly has jumped from ~1.5MB to ~1.78MB between 2007/09/15 10:18 and 2007/09/15 11:23

http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox

Checkins to module PhoenixTinderbox between 2007-09-15 10:17 and 2007-09-15 11:24 : 

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-09-15+10%3A17&maxdate=2007-09-15+11%3A24&cvsroot=%2Fcvsroot

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Sounds like this could be related to bug 392263...

Comment 2

[Igor Bukanov]

Does anybody know the reason behind higher Lk number on Linux then on Mac? I.e. does Mac leaks less indeed, or is it just a reflection of the fact that Mac allocates less? I am asking this since the patch for bug 392263 has not affected RLk/Lk counters on Mac.

Comment 3

[Andrew Schultz]

most of the leak differences (between the before & after build logs) are gtk/font related (FcPatternAddWithBinding, libfreetype, etc):
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1189880580.1189882270.23069.gz

That would suggest that the bug 384112 (rather than bug 392263) checkin caused the change.

Linux leaks more than mac because gtk leaks a lot at shutdown.  This would also mean that if bug 384112 caused the leaks, it's not necessarily the fault of the patch.  Bug 394466 would make us leak a lot less gtk stuff on shutdown.  It's also possible that either patch changes the timing of when things happen and that changes what gtk decides to leak.

Comment 4

[Michael Ventnor]

Bug 384112 did not introduce any new variables or pointers, so I really doubt that the patch is the cause of this regression.

Comment 5

[Igor Bukanov]

Here is the new bloat reported by the log from http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1189880580.1189882270.23069.gz :

--NEW-BLOAT------------------------------------bloat------bloat%-
nsDisplayXULImage                             11880       1.85%
nsDisplayBorder                                8556       1.42%
XPCNativeMember                              224004       1.17%
XPCNativeInterface                             9696       1.00%
nsDisplayBackground                           21864       0.44%
xptiInterfaceInfo                             32280       0.12%
XPCNativeSet                                   6496       0.12%
XPCWrappedNativeProto                         26600       0.11%
XPCWrappedNative                             223384       0.03%

Given the massive amount of XPConnect entities in the leak report, it strongly points to the bug 392263 as the patch there could affect the finalization of XPConnect objects. So I will take out the patch for the bug to confirm that. 

Comment 6

[Igor Bukanov]

Taking the patch for bug 392263 out has not influenced the leak count on fxdbug-linux-tbox. In fact, it increased from Lk:1.76MB to RLk:0B
Lk:1.79MB, see http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1189944720.1189946318.3081.gz&fulltext=1 for details. 

So I will wait couple of more cycles and if the counter stays the same, i will check-in the patch from that bug. 

Comment 7

[Igor Bukanov]

I rechecked-in the patch for bug 392263. With the patch applied again, Lk dropped to 1.55 on the first iteration after the patch was applied, see http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1189948080.1189949558.11853.gz&fulltext=1 . Later, with no commits done, it increased again to 1.75M.

So the patch is not guilty. Retrospectively the guilty verdict could be removed without these take-out/check-in activities. When I initially committed the patch, it broke Mac OSX builds. So I took it out the first time, fixed the build problem and recommitted it again. It provided the first window to see for Lk counters, see the tinderbox for around 2007/09/15 08:09:02. That first check-in decreased Lk from 1.55 to 1.50M. Taking out the patch the first time changed that to 1.53M. It was only during the second commit (with no diffrence in code on Linux) that jump from 1.50 to 1.78M happens.

So if there is an extra leak and not just noise fluctuations, then it is somewhere else.

Comment 8

[Reed Loden [:reed]]

Looks like bug 384112 caused this. I backed out that patch, and Lk numbers are down again.