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

VERIFIED INVALID

Status

SeaMonkey
MailNews: Message Display
VERIFIED INVALID
10 years ago
10 years ago

People

(Reporter: sgautherie, Unassigned)

Tracking

({memory-leak})

Trunk
seamonkey2.0a1
x86
Linux
memory-leak

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

10 years ago
(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)
Flags: blocking-seamonkey2.0a1?
(Reporter)

Comment 1

10 years ago
Notice that the "Browser" Leaks/Bloats increased too...

Comment 2

10 years ago
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

10 years ago
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
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID

Updated

10 years ago
Flags: blocking-seamonkey2.0a1?
(Reporter)

Comment 4

10 years ago
(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 :-<)
(Reporter)

Comment 5

10 years ago
(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
No longer blocks: 418243
Severity: critical → normal
Status: RESOLVED → VERIFIED
Keywords: regression
(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).
You need to log in before you can comment on or make changes to this bug.