the reason for the crash is that AudioProcessorGraph::audioBuffers.object points to some bad memory. but the mystery is this:
the address of AudioProcessorGraph::audioBuffers (i.e., &audioBuffers) changes when we go into the processAudio method.
so the address of &audioBuffers in AudioProcessorGraph::processBlock is one thing, and audioBuffers.object points an actual AudioProcessorGraphBufferHelpers object. then as soon as we go into AudioProcessorGraph::processAudio, &audioBuffers is incorrect, so of course audioBuffers.object is pointing at some random place.
‘this’ has the same address in both methods, so I don’t understand how any of this is possible.
note that this is only a problem with the release build. thanks in advance for your help!
these explicit template instantiations forces these symbols to be exported. But the runtime linker will only load symbols from a shared library that are undefined (and this is how it avoids problems with multiple symbol definitions). since both of those methods were already defined in the Plugin Host, they were not being loaded from my plugin.
So the problem seems to have arisen from some incompatibility between the speed-optimized compilation of the rest of AudioProcessorGraph from my plugin calling into the unoptimized processAudio methods from the Plugin Host.
to fix this I made a release build of Plugin Host and stripped its symbols, but when releasing plugins built with JUCE, one probably needs to take care to make sure that only the necessary symbols are exported.
Please note, if you don’t escape your code with back ticks, the less than < and greater than > signs are eaten up as unwanted html code, so your explicit template instantiation reads identical and might be confusing…
Would be good, if you could edit your post accordingly.
