Problems with VFLib concurrent on Xcode 4.6.3

#1

The VFLib looks very good and i'm now looking into trying the CallQueues in the concurrent module. I'm building an AU/VST plugin on Xcode 4.6.3 with base sdk 10.7. I've copied the VFLib next to the Source, JuceLibraryCode etc. directories in my project tree. I've also added vf_core and vf_concurrent sources to the project. The project builds, but i get a leak assertion failure when i close a debug session i.e. unload the plugin. The leaked object is "Thread". This happens regardless of whether i inherit ManualCallQueue in my AudioProcessor or use it as a member variable. Actually i'm not even doing anything with the queue yet. Simply calling close in the destructor of my AudioProcess class. What could be going wrong here?

*** Leaked objects detected: 1 instance(s) of class Thread
JUCE Assertion failure in juce_LeakedObjectDetector.h:98

I've tried enabling boost, but that ended up in linker errors. I built and installed boost in terminal using the included scripts. I have the library and header search paths in the project settings. Are there any further steps i should take to make VFLib build with boost enabled? Could this fix the leaked object problem?

"boost::detail::get_tss_data(void const*)", referenced from:
Boost::thread_specific_ptr<vf::FifoFreeStoreWithTLS::PerThreadData>::get() const in vf_concurrent.o

"boost::detail::set_tss_data(void const*, boost::shared_ptr<boost::detail::tss_cleanup_function>, void*, bool)", referenced from:
Boost::thread_specific_ptr<vf::FifoFreeStoreWithTLS::PerThreadData>::reset(vf::FifoFreeStoreWithTLS::PerThreadData*) in vf_concurrent.o
Boost::thread_specific_ptr<vf::FifoFreeStoreWithTLS::PerThreadData>::~thread_specific_ptr() in vf_concurrent.o
Symbol(s) not found for architecture x86_64
Linker command failed with exit code 1 (use -v to see invocation)

 

#2

The FifoFreeStoreWithoutTLS member of CallQueue seems to be the problem, since creating a local of one of these anywhere in the code causes the leak checker assertion to fail. Looking further, the call GlobalPagedFreeStore::getInstance() right in the initializer list of FifoFreeStoreWithoutTLS creates a RefCountedSingleton whose reference count never reaches zero. Well i haven't yet had the time to get familiar with all the details of these classes and how they are supposed to work, but as far as i'm able to understand, this looks like a bug.

Could someone more experienced comment on this please?

Edit:

Commenting out the leak assertion reveals, that there are other objects failing also:

*** Leaked objects detected: 1 instance(s) of class Thread
*** Leaked objects detected: 3 instance(s) of class WaitableEvent

The performAtExit actually destroys the GlobalPagedFreeStore and some timer thing. Unfortunately this takes place after the leak detector freaks out. What would be the best way to fix this issue? I can't wait to get coding with the CallQueues and the functors. They appear absolutely awesome!

Edit:

There seems to be a lengthy discussion of the problem in the VFLib: A collection of JUCE modules! (MIT Licensed) thread,

http://www.juce.com/forum/topic/vflib-collection-juce-modules-mit-licensed?page=6

and the What's best practice for GUI change notification? thread.

http://www.juce.com/forum/topic/whats-best-practice-gui-change-notification

#3

There's no real way to get rid of the "Thread" leak. Its not a real leak, its another one of those order of destruction issues.