[Evolution-hackers] massive e-d-s memory leak persuit ...
Hi dudie, So - I started to look at the e-d-s memory explosion situation quickly, took a nice dump from gdb, ran strings on it and the heap has a ton of strings around the place (as you would expect) - [ currently running at only ~60Mb strings /tmp/eds-heap | sort | uniq -c | sort -n gives me: 1666 -CONTACT-UID 1666 -NAME 1736 ION-DEST-NAME 1894 OLUTION-BOOK-URI 2100 -EMAIL 2184 ION-DEST-EMAIL 2318 OLUTION-FILE-AS 2506 OLUTION-LIST 2992 ION-LIST 3058 comp 3321 OLUTION-DEST-EMAIL 3329 OLUTION-DEST-CONTACT-UID 3993 OLUTION-DEST-NAME 4534 pwise://[EMAIL PROTECTED]/;Novell GroupWise Address Book 5343 BEGIN:VCARD 5372 ION-DEST-EMAIL 5504 END:VCARD 5505 VERSION:3.0 6786 ION-DEST-NAME 8606 para 12739 ION-DEST-CONTACT-UID 13642 OLUTION-DEST-CONTACT-UID 18082 OLUTION-DEST-NAME 19252 OLUTION-DEST-EMAIL 21991 prop 32508 ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION; 40253 pA, Where the first column is the count ... 32508 copies of that ATTENDEE string seems a little excessive, as do the (apparently mangled?) OLUTION-DEST-... strings. Does that provide any insight wrt. code to audit for this huge leak ? apparently it afflicts everything from SLED10-SP1 onwards. Also - in general to reduce the (high) e-d-s memory usage, should we be using GQuarks for some of these field names as we store them ? Thanks, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] massive e-d-s memory leak persuit ...
Michael, On Thu, 2008-01-24 at 17:46 +, Michael Meeks wrote: 1666 -CONTACT-UID 1666 -NAME 1736 ION-DEST-NAME 1894 OLUTION-BOOK-URI 2100 -EMAIL 2184 ION-DEST-EMAIL 2318 OLUTION-FILE-AS 2506 OLUTION-LIST 2992 ION-LIST 3058 comp 3321 OLUTION-DEST-EMAIL 3329 OLUTION-DEST-CONTACT-UID 3993 OLUTION-DEST-NAME 4534 pwise://[EMAIL PROTECTED]/;Novell GroupWise Address Book 5343 BEGIN:VCARD 5372 ION-DEST-EMAIL 5504 END:VCARD 5505 VERSION:3.0 6786 ION-DEST-NAME 8606 para 12739 ION-DEST-CONTACT-UID 13642 OLUTION-DEST-CONTACT-UID 18082 OLUTION-DEST-NAME 19252 OLUTION-DEST-EMAIL 21991 prop The majority of those are from the contacts component, but because they are truncated in some form I think they are left overs from previous allocations. I thought I'd fixed all of the major leaks in the addressbook libraries, but maybe some new ones got introduced. That said the ATTENDEE field is from the calendar part, which I have never really looked at. If you can replicate this massive memory usage, could you run e-d-s in massif? Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] massive e-d-s memory leak persuit ...
Hey Michael, We are aware of some situations (I did that in addressbook) where the memory built up can happen. They were fixed later to SLED/SP1 release during late 2.12 and aren't in SLED but are part of trunk already. Candidate for the next support pack. Chen is doing a extensive job of profiling EDS currently for SLED/2.22 releases. Once thing is that the Groupwise Addressbook cache, on a update, wouldn't clear the previous one and just appends everything. Which means if you have 100 and you have a update of 10. Next time your cache would have 210 where as ideally it should have just 110. Just to see, if this is a culprit for you. Just move the .evolution/cache/addressbook/account/Novell GroupWise Address Book some where else and make it resync (showdown evo/eds and start evo and go to addressbook). If the sizes vary a lot, they are affected by that syndrome. There were quite a few bits like these they were fixed post SP1 and are in trunk/2.12 already. GQuarks seems to be a nice idea. I will look at it in some time. Thanks Meeks. -Srini. On Thu, 2008-01-24 at 17:46 +, Michael Meeks wrote: Hi dudie, So - I started to look at the e-d-s memory explosion situation quickly, took a nice dump from gdb, ran strings on it and the heap has a ton of strings around the place (as you would expect) - [ currently running at only ~60Mb strings /tmp/eds-heap | sort | uniq -c | sort -n gives me: 1666 -CONTACT-UID 1666 -NAME 1736 ION-DEST-NAME 1894 OLUTION-BOOK-URI 2100 -EMAIL 2184 ION-DEST-EMAIL 2318 OLUTION-FILE-AS 2506 OLUTION-LIST 2992 ION-LIST 3058 comp 3321 OLUTION-DEST-EMAIL 3329 OLUTION-DEST-CONTACT-UID 3993 OLUTION-DEST-NAME 4534 pwise://[EMAIL PROTECTED]/;Novell GroupWise Address Book 5343 BEGIN:VCARD 5372 ION-DEST-EMAIL 5504 END:VCARD 5505 VERSION:3.0 6786 ION-DEST-NAME 8606 para 12739 ION-DEST-CONTACT-UID 13642 OLUTION-DEST-CONTACT-UID 18082 OLUTION-DEST-NAME 19252 OLUTION-DEST-EMAIL 21991 prop 32508 ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION; 40253 pA, Where the first column is the count ... 32508 copies of that ATTENDEE string seems a little excessive, as do the (apparently mangled?) OLUTION-DEST-... strings. Does that provide any insight wrt. code to audit for this huge leak ? apparently it afflicts everything from SLED10-SP1 onwards. Also - in general to reduce the (high) e-d-s memory usage, should we be using GQuarks for some of these field names as we store them ? Thanks, Michael. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
