ofxPd problem - iOS app crashes in testing, works locally

Any help would be hugely appreciated - as a self-taught coder I’m hoping it’s something simple that I don’t understand….but have spent hours on this.
I’m desperately trying to get an ipad app submitted before Apple’s Feb 1st cutoff for 32 bit apps as I have a performer depending on it.
thanks,
Katharine

Problem: app works locally but crashes in testing (testflight - both ‘old’ and Apple’s version) -
I think I have isolated this to the ofxPd add-on:

I’ve stripped the app down to virtually nothing; replaced the pd patch with a simple audio in/out test…

What happens:
Works locally. But test build crashes after ofSoundStreamSetup (although the app remains open on the iPad). It doesn’t crash if ofxpd setup is commented out.

Crash log indicates only a Thread 0 crash - Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0xfffffff7
Triggered by Thread: 0

Code excerpts ….The ofxpd code was originally pinched from Dan’s examplePitchShifterIOS example

ofApp.mm
//--------------------------------------------------------------
void ofApp::setup() {

    ofSetFrameRate(60);
  //ofSetVerticalSync(true);
    ofBackground(127, 127, 127);
    
    ofRegisterTouchEvents(this);
    
    ofxAccelerometer.setup();
    
    ofxiOSAlerts.addListener(this);
    
    ofSetOrientation(OF_ORIENTATION_90_RIGHT);
    
       int ticksPerBuffer = 8; 
   
    ofSoundStreamSetup(2, 1, this, 44100, ofxPd::blockSize()*ticksPerBuffer, 3);
    core.setup(2, 1, 44100, ticksPerBuffer);  //AppCore.cpp


Appcore.cpp - tried testing with addReceiver commented out in case my addition is the problem.

> /--------------------------------------------------------------
> void AppCore::setup(const int numOutChannels, const int numInChannels,
>                     const int sampleRate, const int ticksPerBuffer) {

> 	// setup pd
> 	if(!pd.init(numOutChannels, numInChannels, sampleRate, ticksPerBuffer)) {
> 		OF_EXIT_APP(1);
>         cout << "exiting PD " << endl;
> 	}

>     //subscribe to receive source names
>     pd.subscribe("Amplitude1");
>     pd.subscribe("Pitch1");


>     pd.addToSearchPath("pd");
>     pd.start();

>     //KN add
>     pd.addReceiver(*this);

>     // open patch
>     Patch patch = pd.openPatch("pd/_testmainplus.pd");
>     cout << patch << endl;

> }

can you try moving ofSoundStreamSetup to the absolute end of setup() ? it’s a thread, and you can sometimes have time issues where things allocated after ofSoundStreamSetup aren’t available by the time the first buffer of audio is ready or requested.

Thanks Zach - I’ve just tried it but no luck, although I was thinking it could be something along those lines.

can you post the smallest possible crashing example? can you post a stack trace if it crashed in debug, and specifically focus on both the audio and the main app thread – see where they are both are at when they crash. Finally, I’ve found slowly commenting out things to be helpful for debugging, starting from the end, working your way back to the start and seeing what thing brings the crash. Also, look at any un-initialized variables or memory access errors – do you have a variable that you didn’t give an initial value? do you have an array that you are accessing incorrectly?

hi thanks - I don’t know enough to know what’s useful but below is part of a recent crash log and I have posted it all at http://bit.ly/1uxKbDk

Yes, I had started from everything commented out, worked back and logged new changes each time - the point that triggers a crash appears to be the setup call for ofxPd but I can’t identify why

core.setup(2, 1, 44100, ticksPerBuffer);

I think I have caught all unassigned variables but will check again… because it would be great if that was it!

[My understanding of build settings is limited and not sure how relevant this is - am deploying to 6.1 (get some tr1/memory error if higher) with armv6 armv7 (have also tried with armv7s included). ]

appreciate you taking a look
Katharine

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0xfffffff7
Triggered by Thread:  0

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libstdc++.6.dylib             	0x374a416a std::string::empty() const + 2
1   PaulsWalk                     	0x00248372 0x4000 + 2376562
2   PaulsWalk                     	0x00248458 0x4000 + 2376792
3   PaulsWalk                     	0x0034694a 0x4000 + 3418442
4   PaulsWalk                     	0x00040b0c 0x4000 + 248588
5   PaulsWalk                     	0x0007777a 0x4000 + 472954
6   PaulsWalk                     	0x0007fda8 0x4000 + 507304
7   PaulsWalk                     	0x0035ee66 0x4000 + 3518054
8   PaulsWalk                     	0x003002f8 0x4000 + 3130104
9   PaulsWalk                     	0x002fd40e 0x4000 + 3118094
10  PaulsWalk                     	0x0035844c 0x4000 + 3490892
11  PaulsWalk                     	0x00360cea 0x4000 + 3525866
12  UIKit                         	0x2cae9d0a -[UIViewController loadViewIfRequired] + 598
13  UIKit                         	0x2cae9a78 -[UIViewController view] + 20
14  UIKit                         	0x2caef94e -[UIWindow addRootViewControllerViewIfPossible] + 58
15  UIKit                         	0x2cb56438 -[UIWindow setRootViewController:] + 832
16  PaulsWalk                     	0x0035fc52 0x4000 + 3521618
17  UIKit                         	0x2cb54530 -[UIApplication _handleDelegateCallbacksWithOptions:isSuspended:restoreState:] + 348
18  UIKit                         	0x2cd4988e -[UIApplication _callInitializationDelegatesForMainScene:transitionContext:] + 3462
19  UIKit                         	0x2cd4b986 -[UIApplication _runWithMainScene:transitionContext:completion:] + 1370
20  UIKit                         	0x2cd56204 __84-[UIApplication _handleApplicationActivationWithScene:transitionContext:completion:]_block_invoke + 32
21  UIKit                         	0x2cd4a214 -[UIApplication workspaceDidEndTransaction:] + 128
22  FrontBoardServices            	0x2fd8f0ce __31-[FBSSerialQueue performAsync:]_block_invoke + 10
23  CoreFoundation                	0x295edd7a __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 10
24  CoreFoundation                	0x295ed03c __CFRunLoopDoBlocks + 212
25  CoreFoundation                	0x295ebb76 __CFRunLoopRun + 1710
26  CoreFoundation                	0x295393bc CFRunLoopRunSpecific + 472
27  CoreFoundation                	0x295391ce CFRunLoopRunInMode + 102
28  UIKit                         	0x2cb4e1ba -[UIApplication _run] + 554
29  UIKit                         	0x2cb48f9c UIApplicationMain + 1436
30  PaulsWalk                     	0x0035781a 0x4000 + 3487770
31  PaulsWalk                     	0x003576c2 0x4000 + 3487426
32  PaulsWalk                     	0x002f6b82 0x4000 + 3091330
33  PaulsWalk                     	0x00036cb6 0x4000 + 208054
34  libdyld.dylib                 	0x3765faac start + 0

can you compile in debug ? (it seems to not be debug stack trace)

1   PaulsWalk                     	0x00248372 0x4000 + 2376562
2   PaulsWalk                     	0x00248458 0x4000 + 2376792
3   PaulsWalk                     	0x0034694a 0x4000 + 3418442
4   PaulsWalk                     	0x00040b0c 0x4000 + 248588
5   PaulsWalk                     	0x0007777a 0x4000 + 472954
6   PaulsWalk                     	0x0007fda8 0x4000 + 507304
7   PaulsWalk                     	0x0035ee66 0x4000 + 3518054
8   PaulsWalk                     	0x003002f8 0x4000 + 3130104
9   PaulsWalk                     	0x002fd40e 0x4000 + 3118094
10  PaulsWalk                     	0x0035844c 0x4000 + 3490892
11  PaulsWalk                     	0x00360cea 0x4000 + 3525866

any chance of posting a small example that crashes?

Can’t say I’m knowledgable enough about OF to know what is going on specifically in your case. However, I have been running an app I made for an iPad that uses ofxPd without a problem. With that said, I made myself some super stripped down template projects for when using ofxPd. Maybe you could build the ios one and see if it works for you? Are the ofxPd examples running without any issues?

ofxPd Templates

thank you zach and michael - even the most stripped down version seems to crash (although not when run in debug connected to ipad locally). I wonder if it’s some build setting thing. I previously made a working app with the same build settings but not with ofxPd.

No, I can’t get a simple ofxPd example to work as a test build outside xcode either – so I think I have to try Michael’s advice and see if I can get further. Thank you so much (for now!) [And will RTFM on debug …]

not a real ‘solution’ but I’ve got it to work by (1) switching back to OF 8.3 for now and reinstalling the addon (2) building up from an example. The original code now works. Who knows…no time to investigate right now.
Huge relief. And thank you for the help.