InterprocessConnectionServer crash on MacOSX


 I'am currently working on interprocess communication beetwen audio plugin.

I use socket to transmit data. However, i’ve got an issue with the InterprocessConnectionServer Class on MacOSX ( on windows it’s fine )
First time i load a plug, it’s ok, interprocess communication works without any hassle.

When i unload the plug and load it a second time, i’ve got the following crash :

Thread 0 Crashed: Dispatch queue: 0 libSystem.B.dylib 0x997baef6 __kill + 10 1 libSystem.B.dylib 0x997baee8 kill$UNIX2003 + 32 2 libSystem.B.dylib 0x9984d62d raise + 26 3 libSystem.B.dylib 0x99863679 __abort + 124 4 libSystem.B.dylib 0x998636f5 abort_report_np + 0 5 0x003cefa4 0x1000 + 3989412 6 libSystem.B.dylib 0x997c01fb _sigtramp + 43 7 ...late-digital.VirtualChannel 0x4d843527 juce::StreamingSocket::close() + 23 (juce_amalgamated.cpp:7499) 8 ...late-digital.VirtualChannel 0x4d993ea4 juce::InterprocessConnectionServer::stop() + 68 (juce_amalgamated.cpp:37436) 9 ...late-digital.VirtualChannel 0x4d993eef juce::InterprocessConnectionServer::beginWaitingForSocket(int) + 31 (juce_amalgamated.cpp:37417)

i bet on a dirty socket close during the unloading of the plug.
I disconnect all active connection on unloading and the InterprocessConnectionServer Class is properly deleted.

Sometimes, call to beginWaitingForSocket() is successfull but the plug hang on the first message sended ( StreamingSocket::write crash)

Any Idea ?


Could be something the host is doing that’s interacting with the OS sockets layer… Have you tried in other hosts? Something else you could do would be to try reproducing it in an app, so you can see exactly what’s going on.


I’ve tried to use interprocess communication in a standalone App as you suggested. It’s working fine.
I’ve tried two differents hosts ( AULab and Logic ) and it crashs.

Crashs seems to be related to connetion threads and occures soon after i try to connect to another plug.
I leave you another crash log, maybe it can help.

Thread 0 Crashed: Dispatch queue: 0 libSystem.B.dylib 0x9975fa34 pthread_mutex_lock + 24 1 ...late-digital.VirtualChannel 0x14df6d2a juce::WaitableEventImpl::signal() + 26 (juce_amalgamated.cpp:237852) 2 ...late-digital.VirtualChannel 0x14cb285b juce::WaitableEvent::signal() const + 31 (juce_amalgamated.cpp:237891) 3 ...late-digital.VirtualChannel 0x14cb29e0 juce::Thread::notify() const + 26 (juce_amalgamated.cpp:15146) 4 ...late-digital.VirtualChannel 0x14d17912 juce::Thread::stopThread(int) + 82 (juce_amalgamated.cpp:15095) 5 ...late-digital.VirtualChannel 0x14d17c60 juce::InterprocessConnection::disconnect() + 150 (juce_amalgamated.cpp:37147) 6 ...late-digital.VirtualChannel 0x14d17f44 juce::InterprocessConnection::connectToSocket(juce::String const&, int, int) + 24 (juce_amalgamated.cpp:37081) 7 ...late-digital.VirtualChannel 0x14baa635 ConsoleGroupsPipe::init(int) + 185 (ConsoleGroupsPipe.cpp:30) 8 ...late-digital.VirtualChannel 0x14babcd2 ConsoleGroupsPipesSingleton::init(int) + 40 (ConsoleGroupsPipesSingleton.cpp:18)


I notice something about a singleton in your stack trace - singletons and statics are never a good idea when you’re writing plugins. Try avoiding that, and giving each plugin its own object to manage. Or if you really must share an object between plugin instances, make it reference counted so that when the last plugin is closed, the object won’t be left floating around.

I need to do interprocess communication beetween two types of plugs and each plus can have many instances.
That’s why i use a singleton and it’s effectively reference counted ( to ensure proper interprocess stuff destruction )

Well… the stack trace kind of looks as if the InterprocessConnection object might be a dangling pointer to me… I’d suggest getting some breakpoints in there to keep an eye on it being deleted.

I checked, all InterprocessConnection and InterprocessConnectionServer are properly deleted.
I even delete the InterprocessConnection returned by the InterprocessConnectionServer ( which was necessary to make the system work as it should under Windows)

Well, that stack trace looks very much like you’re deleting a dangling pointer.

Obviously I assume you’re never actually using the “delete” operator anywhere in your code, and are always using ScopedPointers, so a double deletion is impossible, right…?


It’s working now.