Statics, shared library, and crashes

Audio Plugins
1

Hi everyone,

This is not a JUCE specific problem but it is related to how audio plug-ins are loaded so I suppose it is relevant for some of you.

I’m bringing in the AWS C++ SDK to my project. This SDK is initialised using a static initialise/cleanup function. I’ve created a small RAII class wrapped in a SharedResourcePointer that calls the init and cleanup.

I’m experiencing strange crashes in my plug-in. This is the situation:
When I load multiple VST3 instances, then delete them all and load an AU, it crashes.
When I load multiple AU instances, then delete them all and load a VST3, it crashes.
When I load multiple VST3 instances, then delete them all and load a VST3, it’s fine.
When I load multiple AU instances, then delete them all and load a AU, it’s fine.

I decided to build AWS SDK as a static library in order to simplify the deployment of the product because I wouldn’t need to ship the shared library with the product. The crash is not happening when I build the SDK as a shared library (.dylib).

Just before the crash, an assert happens on assert(s_configManager); in the ConfigAndCredentialsCacheManager.cpp (AWS SDK). The value of s_configManager is only changed during initialisation and cleanup of the API so this is defenitly where things go wrong.

I’m not expecting people here to be experts at AWS SDK, but I’m hoping that someone could give me a lead to what the problem could be. I know that singletons and plug-ins aren’t best friends, but I’ve never experienced this weird behaviour before.

Thank you,
Jelle

2

This sounds a bit like the sort of problems that we encountered recently with protobuf that we link statically in some of our products. I suddenly saw a stack trace going from one plugin to another. It turned out that some misconfiguration in our build scripts had changed the symbol visibility, so that both plugins exposed the very same protobuf function symbols and once the second kind of plugin was loaded, these duplicated symbols shadowed each other at runtime so we got calls across the entities that lead to mysterious crashes. Ensuring that we linked with private symbol visibility again resolved it for us.

2 Likes
3

Thank you! This solved the problem!

I had to play around with cmake a bit to set the visibility setting, this works
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fvisibility=hidden" CACHE INTERNAL "")

this didn’t, does someone know why?
set_property(TARGET ${target} PROPERTY CXX_VISIBILITY_PRESET hidden)

4

I did the same a little bit different:

set(CMAKE_CXX_VISIBILITY_PRESET hidden)
set(CMAKE_VISIBILITY_INLINES_HIDDEN ON)

And in my vcpkg triplet files I added:

set(VCPKG_C_FLAGS "${VCPKG_C_FLAGS} -fvisibility=hidden -fvisibility-inlines-hidden")
set(VCPKG_CXX_FLAGS "${VCPKG_CXX_FLAGS} -fvisibility=hidden -fvisibility-inlines-hidden")
1 Like