The editor is for automotive test equipment such as you see rattling cars in TV commercials. They run on road load data files, recordings from the test track. My editor is described and downloadable via this link.

I do open and close a fair number of windows. To close, I destroy them at top-level like so...

$mw->destroy() if Tk::Exists($mw);

...with the assumption that all said top-level's child widgets are likewise destroyed. Then later I rebuild them when needed. Does destroying a widget not return all memory from them and their children? Is that my problem, or something else?

Thanks,
Gan

I downloaded and ran your program and it produced a bunch of warnings. Most of them are probably benign, at leats with respect to your memory problem, but one group caught my eye and tweaked somthing in my memory:

Variable "@perl_widgets" will not stay shared at P:\test\422088.pl lin
+e 3475.
Variable "@checks_antiflats" will not stay shared at P:\test\422088.pl
+ line 4999.
Variable "@antiflats_cmd" will not stay shared at P:\test\422088.pl li
+ne 5005.
Variable "@antiflats_nb" will not stay shared at P:\test\422088.pl lin
+e 5035.
Variable "@antiflats_ms" will not stay shared at P:\test\422088.pl lin
+e 5056.
Variable "@checks_antiflats" will not stay shared at P:\test\422088.pl
+ line 5076.
Variable "$frame_ps_options" will not stay shared at P:\test\422088.pl
+ line 5087.
Variable "$frame_ps_options" will not stay shared at P:\test\422088.pl
+ line 5104.
Variable "$frame_ps_options" will not stay shared at P:\test\422088.pl
+ line 5122.
Variable "$frame_ps_options" will not stay shared at P:\test\422088.pl
+ line 5138.
Variable "$pythag_flag_last_time" will not stay shared at P:\test\4220
+88.pl line 5163.
Variable "$frame_ps_options" will not stay shared at P:\test\422088.pl
+ line 5169.
Variable "$pythag_flag_last_time" will not stay shared at P:\test\4220
+88.pl line 5192.
Variable "$frame_ps_options" will not stay shared at P:\test\422088.pl
+ line 5218.
Variable "$frame_ps_options" will not stay shared at P:\test\422088.pl
+ line 5318.
Variable "@antiflats_nb" will not stay shared at P:\test\422088.pl lin
+e 5324.
Variable "@antiflats_ms" will not stay shared at P:\test\422088.pl lin
+e 5325.
Variable "$frame_ps_options" will not stay shared at P:\test\422088.pl
+ line 5349.
Variable "@antiflats_nb" will not stay shared at P:\test\422088.pl lin
+e 5366.
Variable "@antiflats_ms" will not stay shared at P:\test\422088.pl lin
+e 5370.
Variable "$frame_ps_options" will not stay shared at P:\test\422088.pl
+ line 5422.
Variable "@antiflats_nb" will not stay shared at P:\test\422088.pl lin
+e 5428.
Variable "@antiflats_ms" will not stay shared at P:\test\422088.pl lin
+e 5429.
[download]

The diagnostics for this warning reads:

Variable "@perl_widgets" will not stay shared at P:\test\422088.pl lin
+e 3475 (#4)
    (W closure) An inner (nested) named subroutine is referencing a
    lexical variable defined in an outer subroutine.

    When the inner subroutine is called, it will probably see the valu
+e of
    the outer subroutine's variable as it was before and during the *f
+irst*
    call to the outer subroutine; in this case, after the first call t
+o the
    outer subroutine is complete, the inner and outer subroutines will
+ no
    longer share a common value for the variable.  In other words, the
    variable will no longer be shared.

    Furthermore, if the outer subroutine is anonymous and references a
    lexical variable outside itself, then the outer and inner subrouti
+nes
    will never share the given variable.

    This problem can usually be solved by making the inner subroutine
    anonymous, using the sub {} syntax.  When inner anonymous subs tha
+t
    reference variables in outer subroutines are called or referenced,
+ they
    are automatically rebound to the current values of such variables.
[download]

I wonder, without being able to find anything to confirm it, if these unshared closures are causing (part of) your memory leak.

As I say, I'm not sure if this could cause such a problem as I have never really understood the diagnostic, but it might be worth your further investigation.

---

Examine what is said, not who speaks.

Silence betokens consent.

Love the truth but pardon error.

Does destroying a widget not return all memory from them and their children? Is that my problem, or something else?

That's your problem. I was burned by the same thing when I built my first "big-long-running" script. If there is one rule I can summarize...you have to REUSE all widgets in Tk, or there will be leaks. Somewhere deep down in the innards of Tk, references to all objects are kept, and not released until the end of the program. I know it is a pain to deal with, but once you learn the tricks, it isn't too bad.

For instance, you say you open a fair number of windows, then destroy them....that is memory use going up. What you want to do, is pre-create a set of reusable top-level windows, each packed with the widgets they need (which will also be reused), and "withdraw" them. Now, when you need to load them with data, loop through them all, and "configure" each of them with the new data, then "raise" the toplevel. When you are done, don't destroy the toplevel, just "withdraw" it. When you need the next toplevel, just loop through the withdrawn toplevel(and it's widgets) and "reconfigure" them with the new data, then "raise" them again.

I have made some big programs run this way, loading, unloading, and reloading data, without memory leaks. The memory will increase to the size of the largest "instance" of the toplevel, but will be reused, and generally will level out at some average value.

Photo objects can be "emptied" with $photo->blank, text widgets can be blanked with $text->delete('1.0', 'end'); etc, etc.

I've found almost all widgets can be reused, without leaking, with the exception of the Progressbar.

Most Tk apps are small, and tend to do something then exit; so the small memory gains, created by using "destroy", can be ignored. But long running scripts have to be caarefully planned.

---

I'm not really a human, but I play one on earth. flash japh