Crash ARA - Align media to detect grid / Import into project: Tempo (FIXED)

[PierreGlt]

ARA plugins crash in Reaper. This is how to reproduce the crash:

- Open Reaper (v6.70)
- Create a track and load an audio file
- Load the JUCE’s ARAPluginDemo (https://github.com/juce-framework/JU...RAPluginDemo.h)
- In the plugin window, select “ARA: Align media to detect grid”
- Crash

I tested it with JUCE 7.0.2 (master) and ARA 2.1.0 (for compatibility). The crash also occurs with my own ARA plugins made with JUCE. You can also encounter a crash if you select “ARA: Import into project: Tempo”. I don’t know if the problem lies in Reaper, ARA, or JUCE.

[PierreGlt]

I tested with JUCE develop (128e980) and ARA SDK 2.2.0 and the problem persists. By the way, here is the crash log.

[vitalker]

I'm not the developer, but I think you should include OS infromation, especially when you are using ARM build.

[PierreGlt]

Yes, of course.

This is from the crash report: macOS 13.0 / M1
Identifier: com.cockos.reaper
Version: 6.70.0_309480du (6.70.0_309480du)
Code Type: ARM-64 (Native)
OS Version: macOS 13.0 (22A380)

The crash also happens on Windows 11 (10.0.22) / Intel i7. I can test on other machines if necessary but I think it doesn't depend on the OS or the architecture.

[vitalker]

Originally Posted by PierreGlt

The crash also happens on Windows 11 (10.0.22) / Intel i7. I can test on other machines if necessary but I think it doesn't depend on the OS or the architecture.

Ah, okay. Sometimes crashes only happen on some OSes, but on others don't, that's why I suggested to add that info.

[PierreGlt]

I created a similar issue on JUCE Forum (https://forum.juce.com/t/crash-ara-r...-tempo/53794/3) and the problem seems on the Reaper side. Reaper should not call DocumentController::createAudioSourceContentReader ().

[schwa]

Thanks for the report. The crash appears to be an assert in the plugin code. We will add a call to isPlaybackRegionContentAvailable() / isAudioSourceContentAvailable() before createPlaybackRegionContentReader() / createAudioSourceContentReader() to hopefully avoid the assert.

[schwa]

This change is in the current prerelease builds, if you'd care to try it out and let us know if it fixes the problem. https://forum.cockos.com/forumdisplay.php?f=37

[PierreGlt]

Thanks for the news. Unfortunately, the plugins still crash. I tested v6.71+dev1204 on macOS 13.0 M1, I can test on other machines if necessary. The assertion is part of the ARA SDK so this is annoying to modify and even if I debug the plugin in Reaper, it doesn't hit the assertion in my code.

I'm only developing ARA plugins and I didn't investigate properly the host part of the ARA SDK but, if it can help, it seems to me that the methods ARA::PlugIn::FactoryConfig::getAnalyzeableContentT ypesCount(), ARA::PlugIn::FactoryConfig::getAnalyzeableContentT ypes() and ARA::PlugIn::FactoryConfig::getSupportedPlaybackTr ansformationFlags() should be used to verify what can do the plugin.

Here is the possible assertion:
https://github.com/Celemony/ARA_Libr...Plug.cpp#L1827

This way, these actions (ARA - Align media to detect grid / Import into project: Tempo) can even be disabled and inaccessible to the user if the plugin doesn't allow them.

[schwa]

Today's build (+dev1205) may quiet down the asserts.

The default ARA assert will terminate the plugin, but ARA does support installing your own assert function. I might suggest installing an assert that does not automatically terminate? If there is functionality that your plugin doesn't handle, it probably makes more sense to log the error and continue rather than terminating.

[PierreGlt]

No more crash with +dev1205. Thank you!

> I might suggest installing an assert that does not automatically terminate?
Indeed, I will try to replace the ARA assert method.