Xcode 8.3 potential memory leaks detection questions

Development
1

So while rebuilding the Plugin Host example app, I looked at the Xcode 8.3.3 compiler warnings/hints and could note a significant amount of potential memory leaks reported issues.

In particular, I was wondering why the example does not use a smart pointer maybe like the ScopedPointer<> class template (maybe a shared_ptr would be more approriate if ref is shared?) when creating a plugin instance in:
InternalPluginFormat::createPluginInstance()
where the p pointer is created locally and then passed to a callback().

Because the callback is passed in parameter in this function it is hard to know if this is going to be a problem or not to not delete this ptr, so why not using a smart pointer there ?

2

We use the plugin host demo all the time and never see any leaks - we’d fix that kind of thing immediately if it happened!

Of course, the plugins that the host loads can (and many certainly will) leak. But if you find a leak in the host app itself, please give us more details and we’ll take a look.

Using smart pointers everywhere is something we’ve been unable to do until recently, as we couldn’t rely on all our users to have compilers that support move constructors until now. We’ll probably start using a more modern style, but even so in trivial cases like the one you mention in InternalPluginFormat, it wouldn’t really add enough semantic value to be worth the extra typing IMHO.

3

Hey Jules,

First thing I want to say is a big thanks for your excellent work and for still been active here today,
this toolkit is certainly the most powerful cross-platform toolkit for audio applications and plugins development I could evaluate so far.

Please read:

I gave the full stack and followed recommendations on how tracking this issue on Github.

Should you have any other questions, please let me know directly there as I handle most of my open source activities on Github.

Thanks again for your time and consideration,
-Fab

4

I could easily reproduce it by having the context menu open and quitting via CMD-Q (when I saw a PopupMenu was leaking, that was my first guess).

1 Like
5

Oh, that’s not really a bug, it’s just that the demo doesn’t bother taking precautions to close modal windows when it’s being shut down.

I’ll add something to do that, as it’s a good example of what you should do when shutting down a real app.

6

I agree,

Which is why other toolkits don’t even bother checking about them when application is closing ; because they rely on modern operating systems automatic memory de-allocation that happens once the corresponding process is gone. I know this is true for at least Windows, Mac OS X and Linux, and since a long time.

It also was a trick to exit faster in the old days, where virtual destructors would consume a significant amount of time for releasing something the OS does release anyway (was not very clean though!).

Now, is it possible to not having false positive warnings when we are sure the application exits ( maybe a log on the console but not an exception in that case or similar) ?

-Fab

7

Well, this wasn’t a false positive, it was a true one… Just not one that really matters. And no, there’s not really any way for the framework to know which allocations you care about!

In this case it was worth me adding some better shutdown code anyway, as there were other edge-cases that wouldn’t have been handled cleanly too.

8

Nice commit here,
Thanks Jules!