Tk Image avoid memory leaks - Windows XP

[m68k]

My monitoring tool uses 10 .GIF images palaced in labels to indicate when specific events occur. This app runs 24x7.

All images are created at the top of the program like this:
#image create photo $icon -file "C:/Path/$icon" -format gif

They are then applied to labels widgets when needed:
#label ".name" -text "text" -image $icon compound "center"

I have read that Tk images can be a source of memory "leaks" on long running processess. One suggestion is to delete all images "when they are no longer needed":
#foreach name [image names] {
# image delete $name
#}

Should I delete and recreate the images every so often to avoid a leak in my app? Or is this suggestion for apps that have the potential to use many different images that may never be used again?

 

[Bong]

Have you noticed any memory leaks or otherwise abnormal behavior?
If not, I'd say leave it alone.

_________________
Bob Rashkin

 

[m68k]

The monitoring tools are currently running on 6 different PC's. The only thing running on these PC's are my tool, antivirus, and normal backend services. It seems that the PC's "lock up" every 30 days or so. You must turn the PC off/on with the power switch. I am wondering if my app could be the root of this?

The bad news is that these PC's are not under my control and they are locked down so tight you can not even access the tack manager to see resources, use run commands, etc. In other words, I can't use normal Windows techniques for monitoring the PC's resources over time. This is why I asked the original question for anyone with an in depth understanding of how Tk images use memory.

 

[thacoda]

m68k, I am not an expert on how tcl/tk manages it's memory in case of images, but I was thinking on how one could solve a problem like this, if no alternative is left, my 2 cents:

if these tcl/tk tools you made are the cause of the PC lockup's (referring to Tk images problem), maybe you should simply include additional script to close/exit your tool on a safe frequency. Since it's only a monitoring tool, I guess, this should be no problem. So, write a script that when time comes, let your tool start up (exec) a copy and exit the version which called the new one.

I would say, a poorman's workaround...but if it works...

thacoda