Hi, I am working on building an installer for my plugin and am running into a strange issue where the AU version shows up and works in Ableton but does not show up in Logic Pro X. I am installing to the path:
First thing to say is that in most hosts the one in the user library will be the ONLY one seen by them. The best thing to do to debug is to run auval.
From terminal I would run auval -a, does your plugin show up? (remember this will likely be the one in the user library ONLY)
If your plugin shows up you should see it in the list for example… aufx bpas appl - Apple: AUBandpass
If you take the first three 4 character codes you can use those in auval to test your plugin. For example to test the above plugin you would run…
auval -v aufx bpas appl
Hopefully this will highlight an issue. If you need further info you can debug with auval in Xcode quite easily.
Select the MyPlugin - AU scheme
Select Edit Scheme…
Select Run on the left
Select the Info tab at the top
In the Executable drop down menu select Other…
Hit Shift + Command + G on your keyboard and type /usr/bin/auvaltool
Enter and select Choose (before you can run this executable from Xcode, you might need to move this executable to another location such as /usr/local/bin or disable integrity protection)
Back in the edit scheme page now, select the Arguments tab at the top
Add an argument such as -v aufx bpas appl (use the values you retrieved from running auval -a), you can add all these as one argument exactly like this.
Now when you build and run the AU scheme it will launch auval and run tests on your plugin - of which you can debug through.
Okay, I realized that something weird is happening where the plugin crashes the aufx validation when opening logic for the first time, but when I rescan for plugins it passes. This also happens with auval test in the command-line. When I use auval -v to run a test on my plugin via the command line, it fails the first time and then passes when I run the test again. This is a weirdly consistent pattern. Here is the error I get from when my plugin fails, failure happens due to a malloc error in the 1 channel render test:
1 Channel Test:
Render Test at 512 frames
PASS
auvaltool(6011,0x7fff7a7f5000) malloc: *** error for object 0x7fdfcc814808: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
/usr/bin/auval: line 11: 6011 Abort trap: 6 arch -x86_64 /usr/bin/auvaltool “$@”
Does this point to anything specific? Is there something I am doing incorrectly in terms of memory management or freeing resources that might be causing this? Also is there any way to get a more specific description of the object causing the error?
My plugin runs with no issues in Ableton, I’ve been testing it there for a while and have never had a crash.
So as the message suggests you need to set a breakpoint in Xcode, for this you will need to use a symbolic breakpoint. To set this in Xcode go to View >> Navigators >> Show Breakpoint Navigator. You should see the left pane change to show you all of your breakpoints (of which there might be none). At the very bottom left of the pane is a “+” symbol, click it to reveal a menu suggesting different types of breakpoints that can be added. Select Symbolic Breakpoint…, in the window that appears, enter malloc_error_break for symbol and hit enter, click away from the window to dismiss it and start debugging.
Okay, I added a symbolic breakpoint as you suggested, but when I run in the plugin host I don’t get any errors. When the auval test fails I get:
auvaltool(2374,0x7fff76f54000) malloc: *** error for object 0x7fe653002a08: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
Which is weird because I did set a malloc_error_break to debug and it didn’t catch anything when I ran it in the JUCE plugin host.
I am catching a leaked object error for some AudioBuffer objects when the plugin passes the auval test:
*** Leaked objects detected: 66 instance(s) of class AudioBuffer
JUCE Assertion failure in juce_LeakedObjectDetector.h:97
The plugin is a reverb with several allpass filters built in, so there are a lot of AudioBuffers being used(not 66 though, so this seems weird). I have several classes in my project that contain an audio buffer (I only use AudioBuffers as a member of a class) declared as follows:
class myClass{
public
myClass(){
myBuffer.setSize(1, MYSIZE);
}
…
private:
AudioBuffer myBuffer;
…
}
Is there some other way I should be declaring these, or freeing them in the class destructor? I am now realizing this is probably pretty bad practice in terms of resource management, but I never noticed it until now since it wasn’t causing any issues.
In each of the classes using an AudioBuffer try adding the macro JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR(MyClass), that might highlight which class is actually the culprit, you’re probably leaking a class containing an AudioBuffer.
You say you’re not hitting the breakpoint when debugging with the JUCE plugin host, but have you attached to auval as suggested earlier on? auval will be doing a lot more than the JUCE host due to the tests it runs on the plugin.
but have you attached to auval as suggested earlier on?
What do you mean by attached to auval? I have tried adding a symbolic breakpoint as you suggested, but this does not seem to have any effect on auval’s operation. The auval error suggests adding a symbolic breakpoint, but how do I make this breakpoint catch an error which happens during the auval test?
For now I will try fixing the memory leak issues and see if that helps. When I run in the JUCE plugin host and quit by closing the plugin host window (not the stop button in Xcode), I get the same type of error:
*** Leaked objects detected: 33 instance(s) of class AudioBuffer
It makes sense that there would be 33 leaked objects since I have 8 instances of a double nested allpass filter class (3 buffers each) and 8 instances of an interpolated delay line class (1 buffer each), for a total of 32 buffer, +1, which is that being passed to process block, for 33. (66 for the auval test was because it tested twice at different buffer sizes). As of right now I don’t think I am freeing any of these resources correctly. Yikes!
I declare arrays of pointers to these classes in my AudioProcessor and then fill them with instances of the class in the AudioProcessor constructor as follows:
delayLine[0] = new delayLine(params…)
I feel like I need to add something to the destructor either for AudioProcessor or for the classes that use AudioBuffer in order to free the buffer instances, because right now both are empty. How do I free them correctly?
Okay, I figured out a way to prevent the leaks, though I am not sure if it is best practice so I’d still appreciate advice on the topic.
I am now declaring the AudioSampleBuffer pointers in my classes and instantiating instances using “new AudioSampleBuffer();” in the class constructor. I am then calling the destructor for the AudioSampleBuffer instances in the class destructor. Then in my Audio Processor I do the following:
myAudioProcessor::~myAudioProcessor()
{
for(int i = 0; i < 8; i++){
dnap[i]->~DoubleNestedAllpass();
line[i]->~InterpolatedDelayLine();
}
}
Is it necessary to call the destructors for all class instances being used in a class in this way, and is this the best way to handle things?
I updated my project to do this everywhere that I am using a Pointer to a class instance, and I am no longer getting any leaks detected. Still occasionally failing the auval test however, so I think something else is causing that.
What I mean is have you set auvaltool (auval is just a script that calls auvaltool) as the executable in Xcode?
If you look at my earlier post I said:
If you need further info you can debug with auval in Xcode quite easily.
Select the MyPlugin - AU scheme
Select Edit Scheme…
Select Run on the left
Select the Info tab at the top
In the Executable drop down menu select Other…
Hit Shift + Command + G on your keyboard and type /usr/bin/auvaltool
Enter and select Choose (before you can run this executable from Xcode, you might need to move this executable to another location such as /usr/local/bin or disable integrity protection)
Back in the edit scheme page now, select the Arguments tab at the top
Add an argument such as -v aufx bpas appl (use the values you retrieved from running auval -a), you can add all these as one argument exactly like this.
Now when you build and run the AU scheme it will launch auval and run tests on your plugin - of which you can debug through.
For every call to new, you will need to have a corresponding call to delete, but it’s best practice to avoid having to call new/delete, so use smart pointers and containers such as ScopedPointer, OwnedArray
Okay, when I run a debug build of my AU using auvaltool as the executable (did indeed have to copy auvaltool to usr/local/bin) it passes every time, but I get a ton of leaked objects detected.
I’ve tried calling the destructor for all these objects, as well as delete for each object (I’ve tried using each one separately as well as both together), in the destructor for my AudioProcessor like so (I realized this is not best practice, but I want to understand why this does not work):
Since I do this for all the class pointers I am using it seems strange to me that only some of the objects leak. If this method is failing to properly release resources why wouldn’t everything be leaking?
Longterm I am going to replace things with ScopedPointers and OwnedArrays, because that seems to be much cleaner, but I’d like to understand what is going on here if possible.
You need to do some reading on how C++ object management works, but the TL;DR is that you must never call those ~ destructor functions manually! It’s a feature that’s only there for experts who really understand what they’re doing!
But why doesn’t calling delete for the class pointers in the AudioProcessor destructor release these resources? Is the destructor for myAudioProcessor not getting called at some point?
Okay, I think I figured out why the plugin passes the auval test in Xcode but not in the terminal, and it has to do with an issue highlighting in another thread I started, where two different version numbers of the plugin are being recognized by Logic. The current version (version number 0 for development) always passes the auval test and is always recognized by Logic. The old version (version 1.0.0, from before I modified the version number) of the plugin fails the test.
When I open Logic’s plugin manager I the current version always shows up as successfully validated, while the old version shows up as having failed validation. I have tried resetting the AudioUnit Cache on my computer several times and rescanning for plugins and this is always the result.
Therefore, when I run auval from the command line I think it does not always pick the correct version of the plugin (but sometimes picks the old version which is somehow stuck in Logic’s memory), and so sometimes fails. When it runs in Xcode it knows exactly which executable to use and therefore always passes.
Very strange issue. Thanks all for sticking with me and helping me figure this out. Hopefully I can find a solution for the multiple versions of the plugin being found by Logic, but I don’t believe this will be an issue for other users, so at least some progress was made.
Okay so apparently that does not fix things, I tried installing on a friends computer which had never before had any version of the plugin installed, and two version numbers are still recognized.
