Audio unit crashing


#1

Still working on porting a plugin to OSX. I'm making it both as a VST-plugin and an Audio Unit.

I've been testing and debugging it in Ableton Live, steinbergs vsttesthost and Reaper in both 32 and 64-bit modes, where it works like a charm, both as Audio Unit and as VST (2.4). I then tried it in Logic, where it crashes the host (some seconds after succesful loading and UI showing).

I then tried it out it in JUCE PluginHost, with the following results: 

Pluginhost crashes when scanning it as VST, and thus can't even test load it.

Pluginhost scans it without problems as Audio Unit, but crashes loading it.

Here are the relevant stack traces of the crashing threads (i tried debugging it while it crashed, but XCode just sends me to some unknown assembly saying EXC_BAD_ACCESS): 

Logic when opening the plugin as Audio Unit:

Crashed Thread:  0  Dispatch queue: com.apple.main-thread


Exception Type:  EXC_BAD_ACCESS (SIGSEGV)

Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000020


VM Regions Near 0x20:

--> 

    __TEXT                 0000000107709000-000000010857f000 [ 14.5M] r-x/rwx SM=COW  /Applications/Logic Pro X.app/Contents/MacOS/Logic Pro X


Thread 0 Crashed:: Dispatch queue: com.apple.main-thread

0   libobjc.A.dylib                   0x00007fff8c3d3f5e objc_release + 14

1   libobjc.A.dylib                   0x00007fff8c3d3230 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 464

2   com.apple.CoreFoundation          0x00007fff8d28cd72 _CFAutoreleasePoolPop + 34

3   com.apple.Foundation              0x00007fff9205947a -[NSAutoreleasePool drain] + 154

4   com.apple.AppKit                  0x00007fff8dfd227e -[NSApplication run] + 736

5   com.apple.AppKit                  0x00007fff8df76bd6 NSApplicationMain + 869

6   com.apple.logic10                 0x0000000107b8e6d9 0x107709000 + 4740825

7   com.apple.logic10                 0x000000010770c044 0x107709000 + 12356

JUCE PluginHost when opening the plugin as Audio Unit:

Crashed Thread:  0  Juce Message Thread  Dispatch queue: com.apple.main-thread


Exception Type:  EXC_BAD_ACCESS (SIGSEGV)

Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000020


VM Regions Near 0x20:

--> 

    __TEXT                 000000010a67f000-000000010ad79000 [ 7144K] r-x/rwx SM=COW  /Users/USER/Desktop/*/Plugin Host.app/Contents/MacOS/Plugin Host


Thread 0 Crashed:: Juce Message Thread  Dispatch queue: com.apple.main-thread

0   libobjc.A.dylib                   0x00007fff8c3d3f5e objc_release + 14

1   libobjc.A.dylib                   0x00007fff8c3d3230 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 464

2   com.apple.CoreFoundation          0x00007fff8d28cd72 _CFAutoreleasePoolPop + 34

3   com.apple.Foundation              0x00007fff9205947a -[NSAutoreleasePool drain] + 154

4   com.apple.AppKit                  0x00007fff8dfd227e -[NSApplication run] + 736

5   com.rawmaterialsoftware.pluginhost    0x000000010a88b1a7 juce::MessageManager::runDispatchLoop() + 119 (juce_mac_MessageManager.mm:236)

6   com.rawmaterialsoftware.pluginhost    0x000000010a88b0b0 juce::JUCEApplicationBase::main() + 352 (juce_ApplicationBase.cpp:235)

7   com.rawmaterialsoftware.pluginhost    0x000000010a88aeec juce::JUCEApplicationBase::main(int, char const**) + 60 (juce_ApplicationBase.cpp:213)

8   com.rawmaterialsoftware.pluginhost    0x000000010a68f8a3 main + 51 (HostStartup.cpp:102)

9   libdyld.dylib                     0x00007fff860c77e1 start + 1

JUCE PluginHost when scanning the plugin as VST 2.4:

Crashed Thread:  0  Juce Message Thread  Dispatch queue: com.apple.main-thread


Exception Type:  EXC_BAD_ACCESS (SIGSEGV)

Exception Codes: EXC_I386_GPFLT


Thread 0 Crashed:: Juce Message Thread  Dispatch queue: com.apple.main-thread

0   libobjc.A.dylib                   0x00007fff8c3d3f5e objc_release + 14

1   libobjc.A.dylib                   0x00007fff8c3d3230 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 464

2   com.rawmaterialsoftware.pluginhost    0x000000010efbb1a2 juce::MessageQueue::deliverNextMessage() + 130 (juce_osx_MessageQueue.h:84)

3   com.rawmaterialsoftware.pluginhost    0x000000010efbb0ea juce::MessageQueue::runLoopCallback() + 58 (juce_osx_MessageQueue.h:90)

4   com.rawmaterialsoftware.pluginhost    0x000000010efbb0a5 juce::MessageQueue::runLoopSourceCallback(void*) + 21 (juce_osx_MessageQueue.h:100)

5   com.apple.CoreFoundation          0x00007fff8d26eb31 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17

6   com.apple.CoreFoundation          0x00007fff8d26e455 __CFRunLoopDoSources0 + 245

7   com.apple.CoreFoundation          0x00007fff8d2917f5 __CFRunLoopRun + 789

8   com.apple.CoreFoundation          0x00007fff8d2910e2 CFRunLoopRunSpecific + 290

9   com.apple.HIToolbox               0x00007fff90647eb4 RunCurrentEventLoopInMode + 209

10  com.apple.HIToolbox               0x00007fff90647c52 ReceiveNextEventCommon + 356

11  com.apple.HIToolbox               0x00007fff90647ae3 BlockUntilNextEventMatchingListInMode + 62

12  com.apple.AppKit                  0x00007fff8dfdb533 _DPSNextEvent + 685

13  com.apple.AppKit                  0x00007fff8dfdadf2 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128

14  com.apple.AppKit                  0x00007fff8dfd21a3 -[NSApplication run] + 517

15  com.rawmaterialsoftware.pluginhost    0x000000010efac1a7 juce::MessageManager::runDispatchLoop() + 119 (juce_mac_MessageManager.mm:236)

16  com.rawmaterialsoftware.pluginhost    0x000000010efac0b0 juce::JUCEApplicationBase::main() + 352 (juce_ApplicationBase.cpp:235)

17  com.rawmaterialsoftware.pluginhost    0x000000010efabeec juce::JUCEApplicationBase::main(int, char const**) + 60 (juce_ApplicationBase.cpp:213)

18  com.rawmaterialsoftware.pluginhost    0x000000010edb08a3 main + 51 (HostStartup.cpp:102)

19  libdyld.dylib                     0x00007fff860c77e1 start + 1

Another one from Logic Pro X

Crashed Thread:  0  Dispatch queue: com.apple.main-thread


Exception Type:  EXC_BAD_ACCESS (SIGSEGV)

Exception Codes: KERN_INVALID_ADDRESS at 0x00000005472d1ec8


VM Regions Near 0x5472d1ec8:

    __LINKEDIT             0000000201b74000-0000000201be3000 [  444K] r--/rwx SM=COW  /System/Library/Extensions/GeForceGLDriver.bundle/Contents/MacOS/GeForceGLDriver

--> 

    JS JIT generated code  00004b2881800000-00004b2881801000 [    4K] ---/rwx SM=NUL  


Application Specific Information:

objc_msgSend() selector name: dealloc



Thread 0 Crashed:: Dispatch queue: com.apple.main-thread

0   libobjc.A.dylib                   0x00007fff8c3cf259 objc_msgSend + 25

1   libobjc.A.dylib                   0x00007fff8c3d3230 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 464

2   com.apple.CoreFoundation          0x00007fff8d28cd72 _CFAutoreleasePoolPop + 34

3   com.apple.Foundation              0x00007fff9205947a -[NSAutoreleasePool drain] + 154

4   com.apple.AppKit                  0x00007fff8dfd227e -[NSApplication run] + 736

5   com.apple.AppKit                  0x00007fff8df76bd6 NSApplicationMain + 869

6   com.apple.logic10                 0x0000000105b956d9 0x105710000 + 4740825

7   com.apple.logic10                 0x0000000105713044 0x105710000 + 12356

I can't really gather much from these traces (besides none show any stack frames from my plugin). I initially thought the problem to be in the module initialization, but i dont have any considerate statics/globals and i spawn no threads. But again, Logic does actually show the plugin UI and then crashes a couple of seconds later.
What they all have in common is crashing in this frame: (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 464
after sending a message (usually dealloc) to an Objective C-object. Now i dont directly use Objective-C objects anywhere in my code, but i guess they're a huge part of the codebase anyway.

I tried running it through auval, but it can't find the plugin (even though it is located in both /library/audio/plugins and /users/z/library/audio/plugins).

 

The weird thing is, of course, that the exact same binary works without problems in both ableton and reaper (oh and the same code works perfect on windows as VST as well). The plugin is 64-bit in this case (Logic doesn't support anything else). Any insight?


#2

Why are you guessing about all this stuff rather than just using your debugger to catch the crash and see what happened?


JUCE_AUTORELEASEPOOL BAD_ACCESS in VST destructor
#3

Well as said in the topic, i did debug it. Problem is, the problem happens in neither juce library code or my source code. I would consider debugging assembly if i had something like ollydbg at my hands, but xcode neither shows registers, stack frames / automatic variables or makes analysis.

The problem, as indicated by the stack traces, is in [NSApplication run], and the most toplevel call for the fault is this (should you be interested):



Here's the site of the crash (not very informative, either):

 


#4

Right, I see.. Yes, not very helpful!

The only time I've seen stuff like that has been when the host hangs onto a reference to an obj-C object (usually an NSWindow or view) and makes a call to it after the plugin's DLL has been unloaded from memory.


#5

Hmm yeah.. That shouldn't be the case, I'm not messing with objects from objective-c or bundles/dylibs directly. Is there anyway to debug the object that is recieving the message? The fact that the faulting address violation is always 0 + 0x20, and the assembly states something like this (pseudo code):

    struct object
    {
        char pad[0x20]; // vftable / selectors?
        // some kind of virtual function
        void (* somefunc)(void); // 0x20 -- this + 32 bytes: release/destructor/dealloc?

        ...
    };

    void nsapplication_run(void)
    {
        while( ... )
        {
            object * currentObjectFromSomeOperation = objectRelatedToEvent();

            ...

            try {
                __objc_release(currentObjectFromSomeOperation);
            }
            catch (...)
            {
                // never reaches here, system exception thrown
            }
        }
    }

    void __objc_release(object * o)
    {
        if(object)
        {
            // the code doesn't check this:
            //if(object->somefunc)
            // so it might dereference a null pointer here
            object->somefunc();
        }
    }

Seems to indicate that that it is not a problem with a null-object, but rather something like an invalid/corrupt/free'd object.

edit: 

Here's a similar fault: http://stackoverflow.com/questions/13345378/why-does-this-simple-nswindow-creation-code-trigger-an-autorelease-pool-crash-on

It seems to be a problem with automatic reference counting and/or 'zombies'.


#6

Okay so after hours of fruitless debugging, it tried slowly shaving off code until everything that was left was a completly empty class (nothing besides what is needed, and no editor, no members etc.) - and i still got the same error.

 

I created a new project with introjucer, tested that it works (it did), and copy pasted the code into my project. Still crash. It must have something to do with build settings / some excotic resource/info.plist problem. Ill try to do a complete recreation of the project (sighhhh)


#7

Bizarre.. Can't think of any helpful suggestions, but keep me posted with any clues you find..


#8

Not sure if you solved your problems, but here are a few settings in xcode that might help you track them down (you might know this already, but it is non-obvious, so I'll put a few tips here for anyone that stumbles across this thread looking for debug help):


there is a stack slider in the lower left to control the stack frame filtering, set to the far right position turns filtering off for the selected thread.


'register read' in the lldb window prints the general purpose registers


debug workflow -> show assembly while debugging will show assembly where you step in


expanding the variables window in the lower right will let you view  variables, or  hover in the code and use the 'i' icon to print them. use ' Add Expression' to add a custom variable

 

those are just a few, but it might help address some of the concerns in post #3.  There is also a view memory function for the variables window to view their raw contents if that is useful

viewing dissassembly:

http://imgur.com/ZrY3j82

viewing memory:

http://imgur.com/d0EJ3k6

 

Hope that helps.