Segfault in ValueTree listeners


#1

I’m porting an audio application to a plugin, and hit some segmentation faults triggered by ValueTree::sendPropertyChangeMessage.

The original audio app, and the standalone plugin build do not exhibit this issue. I initially assumed it was something to do with the editor being instantiated at a different time to the processor, but after some refactoring I’m not so sure.

This is my first proper plugin project (after 4 years of using JUCE!), so I may be a little green regarding the finer areas of thread safety in the context of a plugin. Any tips on debugging such errors would be very much appreciated.


#2

2 cents:
missing disconnect held by instance created when DAW lists all plugins.


#3

ValueTrees are very thread-unsafe, you have to be careful that all the methods are happening on the message thread… Does that sound likely?


#4

Address Sanitiser is your friend here (and maybe TSan if it is a threading issue)


#5

Thanks, I have a feeling its linked to setting ValueTree properties from different threads.
I’ll look at Address Sanitiser, been a while since I used it, cheers.


#6

For some reason Address Sanitiser seems to crash with EXC_BAD_INSTRUCTION, both with Ableton and Plugin Host.
Trying TSan I get:

==84359==ERROR: Interceptors are not working. This may be because ThreadSanitizer is loaded too late (e.g. via dlopen). Please launch the executable with:
DYLD_INSERT_LIBRARIES=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/lib/darwin/libclang_rt.tsan_osx_dynamic.dylib
“interceptors not installed” && 0

(I tried the suggested line in the schemes argument options but no luck)

Removing lots of my ValueTree listeners seems to have stopped those crashes at least, but now I’m seeing some other crashes on ActionListeners. Seems very hard to debug as, as far as I can see its impossible to find out what listener and which line is actually causing the crash. So feel like I’m shooting in the dark…

I also checked and it seems that all the Listener calls are on the main thread.

My current feeling is that a whole rewrite of the plugin’s messaging/listener system may be in order. But in any case I’d like to understand whats happening.


#7

I’ve not really used ActionListeners but the following should work for that as well as ValueTrees.

I’d hack JUCE and just add a
jassert (MessageManager::getInstance()->isThisTheMessageThread())
call in all the ValueTree action constructor (the ones that subclass UndoableAction).

That should let you know if you’re doing any dodgy threading there pretty quickly…