found a small bug.. we were using ::CxImage::IsAnimated instead of ::picture::IsAnimated... this made us ignore the 'animated files cache' feature i made... I also think that I just found our main huge memory leak!!!!! wouhouuuu !! :) it was simple.. whenever we created a new image, we would read its data from the file into a new object, well, we never freed that object! (thought tcl would do it, seems not!) so every [image create photo] generated one image + additional 'floating' memory of the same size as the image's file... this was affecting the image create -file.. or the image create -data.. or any of the ::CxImage procs!! (resize, crop, IsAnimated!...)

This is also the memory leak we had before!!! you remember? that memleak about amsn segfaulting after allocating GBs of memory and we realized it happens most of the times in the auto-reconnect thing ? well.. the auto-reconenct called cmsn_draw_reconnect proc.. which would [image create photo logoanim -file logoanim.gif].. which means, even if the image creates a new image using the old image's name (hence, the old image was deleted, so no memleaks there), the problem was still that every [image create] generated a little bit of memory leaking somewhere.. so we finally got after many hours of retries, a huge enogh memleak for the kernel to notice us and kill our process!!! I think that's the problem! first, I had fixed that last time by doing a [::skin::loadPixmap logoanim] instead of an image create photo everytime, so we should have been secure.. but now, we should be even more secure!
LZ!!! please confirm it's fixed!

IMPORTANT : You need to recompile TkCximage!!!!!


KaKaRoTo




On Thu, 02 Feb 2006 13:10:25 -0500, Lz <[EMAIL PROTECTED]> wrote:

no, i'm not using displaypics in CL.

heh, i'm sorry if i seemed angry, but i thought nobody paid attention to my
reply to your other mail... this is an important thing :P

On 2/2/06, Youness Alaoui <[EMAIL PROTECTED]> wrote:

ok ok, we heard you :P
I'm in exams so can't look much into that, but try to find one of my old
emails where I gave some hints on how to find a memleak with tcl (info
procs, info globals, namespace names, info vars $::each_namespace::*, loop
through them, output to file the length of each variable, or lenght of
[array get], and then, looking at the outputed file, we could see which
var takes the most space... (hence, the memleak).. we have two choices..
1 - it comes from tcl vars/procs, in that case, that code of mine would
help (problem is to find it.. hope SF search engine is good enough)
2 - it comes from TkCximage, in which case a good study of the proc should
be done
3 - we know it's from the cmsn_draw_online + ShowUser, so a study of those
procs might reveal something

I can't do it unfortunatly...
LZ, r u using dps_in_cl ? if you disable them, is the memleak still there
? make sure of that, it will shorten the scope of the research!

KKRT

On Thu, 02 Feb 2006 08:07:37 -0500, Lz <[EMAIL PROTECTED]> wrote:

> Well, i had to use that subject since i've been "attacked" again today.
>
> It's about what Youness said, everytime contact list gets redrawn, amsn > takes a lot of mb's memory (in my case it takes like 2mb). A couple days
> ago
> when i woke up my computer was completely frozen, i managed to run "top"
> and
> (half an hour later) i saw amsn was taking 76% memory (between ram and
> swap
> that means like more than 1Gb memory). My computer had not unfrozen
> until i
> managed to kill wish (took about five minutes for the shell to manage
> that
> order, lol).
>
> Today when i woke up, my computer was frozen and stuck again, i couldn't
> identify to the screensaver, and neither i could kill x windows nor
> switch
> to console, so i had to telnet from another computer (took about 5
> minutes
> to login) and kill wish from there.
>
> I found out a contact of mine has a buggy client or so, which makes him
> switch from busy to no activity and from no activity to busy like
> three/four
> times a minute when he's away. He left him computer turned on tonight
> and my
> amsn had to redraw the contact list some hundreds of time...
>
> This should be fixed, since it can cause a DoS and completely paralyze a > system in a couple minutes (imagine someone switching him nickname high
> speed, so every amsn in him contact list collapses the system...).
>
> I hope someone heard me now :P
>
> --
> Lz ([EMAIL PROTECTED]).
> http://elezeta.bounceme.net



--
KaKaRoTo


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel




--
Lz ([EMAIL PROTECTED]).
http://elezeta.bounceme.net



--
KaKaRoTo


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel

Reply via email to