Logic Failed AU Validation - Bad Max Frames

My AU plugin has always had intermittent issues being validated in Logic. The solution has always been to Reset and Rescan over and over until it validates, which it eventually does. Annoyingly, this only happens with the Release version, not the Debug version, so I’ve been reluctant to fix it.

However, I noticed that when validating the debug version the auval tool shows:

1 Channel Test:
Render Test at 512 frames

Bad Max Frames - Render should fail
2018-12-03 15:55:49.510486-0500 auvaltool[50306:3117858] kAudioUnitErr_TooManyFramesToProcess : inFramesToProcess=8192, mMaxFramesPerSlice=512

../../../../ JUCE/modules/juce_audio_plugin_client/AU/CoreAudioUtilityClasses/AUBase.cpp:1447 inFramesToProcess=8192, mMaxFramesPerSlice=512; TooManyFrames
from AU (0x8c4821cb): 'aumu' 'Prim' 'AudG', render err: -10874

That’s also the point where the Release version fails. So it looks like this frame issues is to blame. Is there any way to prevent the number of frames from going over?

What you’re showing is the expected behavior.
If it won’t fail then it won’t validate…

Here is the JUCE demo plug-in (old one already compiled on my system):

Bad Max Frames - Render should fail
../../../../modules/juce_audio_plugin_client/AU/CoreAudioUtilityClasses/AUBase.cpp:1447 inFramesToProcess=8192, mMaxFramesPerSlice=512; TooManyFrames
  from AU (0x85dfa090): 'aumf' 'Jcdm' 'ROLI', render err: -10874

mind the PASS as this is expected and correct behavior. it should fail…

in release it’ll just show less details…
This is NI Massive result as an example:

Bad Max Frames - Render should fail

Except, when the Release version gets to the render test, it crashes validation:


Output Format: AudioStreamBasicDescription:  2 ch,  44100 Hz, 'lpcm' (0x00000029) 32-bit little-endian float, deinterleaved
Render Test at 512 frames

validation result: crashed validation

I Reset and Rescan about 20 times and it only passed once. I did notice though that the above crash is happening before the Bad Max Frames. So while it does have something to do with the Render, it may not be associated with the render error -10874.

Any suggestions on how to sniff this out? It passes in Debug so I have no way to trace it.

I had a similar case where the Debug plugin was properly validating but the Release version was crashing the validation. Was at very high sample rate (like 192000 or something). Turned out there was a problem at my end, but the debug would ignore it.

I guess you need to look deeper into your rendering code.


Have you tried commenting out the code in your processBlock to try and narrow down the problem? (Assuming that auval is suggesting that its crashing in the render function)


Also in my experience, when something runs fine in debug and crashes in release its often caused by an uninitiated variable, i.e. a pointer that isn’t initiated kingly gets set to nullptr in debug mode, but in release mode its set to garbage.

Maybe pluginval can give you a hint?

It passes validation in pluginval.

if it crashes validation don’t you get a crash log? did you try not stripping symbols, usually you’d get a stack-trace which might provide some idea of where the crash happens.

I’ve just started getting this also, though it sill passing…

Took all day but I found it. I utilize the playhead position to sync the LFO, and the playhead position info was coming in wonky resulting in a NaN value that should have been an integer, which in turn was used as an array index and thus crash.

Thanks for the help everyone.


This is something that put me into trouble some time back. I (wrongly) assumed that running pluginval at the highest level (10) would at least include the auval validation level. Turns out my plugin was passing all level 10 tests in pluginval, but crashing in auval.

I’d like to include running auval from pluginval but it’s not really possible because you need to have the plugin installed in the system library (IIRC, auval won’t find it from the user library).

Basically I didn’t want to give false hope that auval was correctly being run for AUs when it could fail. Half the point of pluginval is that you can just validate it from the command line with a file path in your build system.

Hope that clarifies things.

1 Like

No problem. It’s in no way a criticism of the great work you have done. Just that this should maybe be highlighted somewhere, as it caused me to release a plugin update that was not passing AU validation.

  1. auval - you can query the proper ids and it will run from user folder. only problem is that for brand new plug-ins or id changes with High Sierra or higher you’ll might need to restart…

  2. pluginval should be greater and better than auval I guess. and as it is open-source and gets improved all the time it’s always possible to try and add things similar to what they do.

And it’s this kind of flakiness that makes me hesitant to add it…
What happens if it’s run on a CI server like Travis which is effectively a new machine each time?

If someone wants to give it a go and create a pull request I’ll definitely take a look…

1 Like