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

[Dominic M. <do...@au...>]

Vaughan Johnson wrote:
> 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").

Somewhere in the wxWidgets documentation it mentioned that you shouldn't
always trust this.  I can't seem to find it now, though...

> 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 usually don't worry about memory that is small and only gets allocated
once.  I compare the leaks you get when starting and stopping Audacity,
to the leaks you get when you run it for a while and use a lot of
functions - only the latter ones are really important.

The main advantage of getting rid of all memory leaks is that it makes it
much easier to debug, because you'll see immediately when you introduce a
new one.  I use this trick all of the time when I'm developing a
self-contained program or library.  But for a large project like Audacity
that depends on so many other libraries, it's almost impossible, because
every sublibrary has its own leaks (or things that look like leaks to the
debugger even though they're harmless).

> 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?

I don't think it would be impossible to remove these memory leaks, it's
just of dubious value if they're small and unimportant.

> 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?

Let's move this to the devel list.  Since I don't use Visual Studio, can 
you copy-and-paste a list of the leaks into a message?

- Dominic