428685 - "Linux nye Dep bloat", Mail Lk/MH/A increased on "2008/04/12 00:54:00"

Status: VERIFIED INVALID

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Serge Gautherie (:sgautherie)]

(FTR, bug 423703 was fixed before all this.)


Very first run:
{{
2008/04/09 20:58:00

Mail RLk:0B
Mail Lk:687KB
Mail MH:13.3MB
Mail A:268K
}}
(Thanks for setting this up !)

... (perfectly stable)


First "minor" change in "Mail A":
{{
2008/04/11 22:54:00

Mail RLk:0B
Mail Lk:687KB
Mail MH:13.3MB
Mail A:269K     [+ 1 K]
}}
From
<http://bonsai.mozilla.org/cvsquery.cgi?module=MozillaTinderboxAll&date=explicit&mindate=1207973580&maxdate=1207979639>
2 "non test" checkins only, nothing MailNews specific.

New "Mail Lk" (and bloats), in next build (coincidence !?):
{{
2008/04/12 00:54:00

Mail RLk:0B
Mail Lk:798KB     [+ 111 KB]
Mail MH:18.3MB     [+ 3 MB]
Mail A:456K     [+ 187 K]
}}
From
<http://bonsai.mozilla.org/cvsquery.cgi?module=MozillaTinderboxAll&date=explicit&mindate=1207979640&maxdate=1207986839>
1 "non test" checkin only:
"2008-04-11 23:07	edward.lee%engineering.uiuc.edu 	...  	Bug 418243 - Removing active autocomplete textbox breaks all autocomplete functionality. r=gavin, b1.9=beltzner, a1.9=beltzner. Fixes Bug 404135 - 'Restore Default Set' in 'customize toolbar' window breaks the location bar (autocomplete, submitting) and the search bar (autocomplete)"

See
<http://ajschult.homelinux.org:8080/graph/query.cgi?testname=mail_trace_malloc_leaks&units=bytes&tbox=nye_bloat&autoscale=1&days=7&avg=1&showpoint=2008:04:12:09:14:08,817535>
<http://ajschult.homelinux.org:8080/graph/query.cgi?testname=mail_trace_malloc_maxheap&units=bytes&tbox=nye_bloat&autoscale=1&days=7&avg=1&showpoint=2008:04:12:09:14:08,19201406>
<http://ajschult.homelinux.org:8080/graph/query.cgi?testname=mail_trace_malloc_allocs&units=count&tbox=nye_bloat&autoscale=1&days=7&avg=1&showpoint=2008:04:12:09:14:08,467164>


... (stable since then)

Comment 1

[Serge Gautherie (:sgautherie)]

Notice that the "Browser" Leaks/Bloats increased too...

Comment 2

[Ed Lee :Mardak]

Is this us? Is there some strange xpconnect leak going on?

> Mail Lk:798KB     [+ 111 KB]
> Mail MH:18.3MB     [+ 3 MB]
> Mail A:456K     [+ 187 K]

All that changed was going from a conditional assignment to an unconditional one, but logically does nothing different.

Comment 3

[Andrew Schultz]

ya, I applied Standard8's second patch from bug 427980, which opens the compose window and causes more allocations, increases the max heap and triggers some additional leaks (might just be more leaks from system libs).

Browser Lk went up on the /next/ cycle, but browser max heap went down.  I don't see anything in the checkins for that next cycle that would have caused leaks.  logs just show changes in leaks for pango and friends.

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1207989840.1207991044.18911.gz

Comment 4

[Serge Gautherie (:sgautherie)]

(In reply to comment #0)
> (FTR, bug 423703 was fixed before all this.)

(Oh well, that bug was for Windows, and the current leaks are monitored on Linux :-<)

Comment 5

[Serge Gautherie (:sgautherie)]

(In reply to comment #2)
> Is this us? Is there some strange xpconnect leak going on?

I thought not, but that was the only hint I had.
Sorry.


(In reply to comment #3)
> ya, I applied Standard8's second patch from bug 427980, which opens the compose

Ah, you did it manually, that's why it didn't show up in bonsai...
(Adding a comment on the tinderbox page could have been forth it, if that's possible.)

> window and causes more allocations, increases the max heap and triggers some
> additional leaks (might just be more leaks from system libs).

Then, do you think it's worth opening another bug (or morph this one) to try and look into these leaks, for the time being ?

> Browser Lk went up on the /next/ cycle, but browser max heap went down.  I

Right !

> don't see anything in the checkins for that next cycle that would have caused
> leaks.  logs just show changes in leaks for pango and friends.

I don't have a clue either:
<http://bonsai.mozilla.org/cvsquery.cgi?module=MozillaTinderboxAll&date=explicit&mindate=1207986840&maxdate=1207989839>


V.Invalid

Comment 6

[Mark Banner (:standard8)]

(In reply to comment #5)
> > window and causes more allocations, increases the max heap and triggers some
> > additional leaks (might just be more leaks from system libs).
> 
> Then, do you think it's worth opening another bug (or morph this one) to try
> and look into these leaks, for the time being ?

No. Not unless you file bugs on the specific leaks. These are not new leaks, and a tracking bug is just a waste of time in this case. They are documented where its visibile (i.e. tinderbox), so they won't be forgotten, a separate bug will probably just sit there and do nothing, especially as it would be hard to define the pass case (ok, that's probably leaks = 0, but how long would it take to get there... probably post Mozilla 2 at a minimum based on FF having leaks in core 1.9).