[Audacity-nyquist] Re: leaky (?) xlisp

[Vaughan J. <vjo...@co...>]

Thanks for the explanation, Roger & Dominic. Yes, what I saw was at 
program exit. I just hadn't noticed it before and wanted to bring it up.

One of the easy ways I'm alerted to memory leaks in C++ code is when MS 
Visual Studio debugger dumps heap allocations that didn't get cleaned up 
before program exit (which it refers to as "memory leaks"). Many of the 
C++ class instantiations get destroyed long before app exit, & if they 
allocated something on the heap and didn't clean it up in their 
destructor or earlier, that leakage shows up in the post-execution dump. 
There is also in that dump, of course, memory that was allocated, still 
in use, and not intended to be cleaned up at exit. I didn't know there 
was any that wasn't intended to be cleaned up. I'm using a new version 
of Visual Studio and it puts this info very much more in my face. I 
thought some time ago that Audacity was free of these, so was surprised 
to see so many.

I thought the dump showing unfreed xlisp memory might indicate a problem 
in xlisp, but I can understand that there's no reason to waste time 
doing garbage collection at exit. I'm guessing you can't just delete the 
symbol table altogether in the xlisp destructor? Can't tell its size 
without traversing the whole thing?

Dominic, should I move this discussion to the dev list? Even if I just 
open the app and close it, there are a few unfreed heap allocations at 
exit, in AUDACITY_1_2 as well as HEAD. Are we just not worried about that?

-Vaughan