Xcode/iOS - archiving: 32 bit release works, and 64 bit debug works, but 64 bit release does not work

I have no problem archiving and then installing and running an app (through either Ad Hoc or TestFlight) on my 32 bit iPad when archiving is set to release. For my 64 bit iPad, it will install but not run if archiving is set to release. However, if I set archiving to debug, it will install and run on my 64 bit iPad.


The crash log presents the following:


Exception Type: EXC_BAD_ACCESS (SIGSEGV)

Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000008

Triggered by Thread: 0


I haven't been able to symbolicate, as there is no dSym file.


I'm using Objective C and using ARC, but I also have two sub-projects: libpd and OpenFrameworks, both of which have ARC turned off.


I'm completely baffled. Can anyone offer a clue?

Replies

That would indicate a dereference of NULL more than likely, but without a backtrace it is pretty difficult to understand where or possibly why.

This the backtrace that I now have:


0   Infinity                     
0x0000000100346fec phasor_dsp + 40
1   Infinity                     
0x000000010034d1cc ugen_doit + 496
2   Infinity                     
0x000000010034d1cc ugen_doit + 496
3   Infinity                     
0x000000010034cd54 ugen_done_graph + 956
4   Infinity                     
0x0000000100356800 canvas_dodsp + 240
5   Infinity                     
0x0000000100355250 canvas_start_dsp + 84
6   Infinity                     
0x000000010037fe28 glob_evalfile + 156
7   Infinity                     
0x0000000100396044 +[PdBase openFile:path:] + 88
8   Infinity                     
0x000000010001e964 -[PdPatch initWithFile:] (PdPatch.m:20)
9   Infinity                     
0x000000010001b844 -[ViewController viewDidLoad] (ViewController.mm:38)
10  UIKit                       
0x0000000187594c40 -[UIViewController loadViewIfRequired] + 996
11  UIKit                       
0x0000000187594844 -[UIViewController view] + 28
12  Infinity                     
0x000000010001ceb4 ofApp::setup() (ofApp.mm:20)
13  Infinity                     
0x00000001003a48cc std::__1::__function::__func<std::__1::shared_ptr<of::priv::Function<ofQuaternion, std::__1::recursive_mutex> > ofEvent<ofQuaternion, std::__1::recursive_mutex>::make_function<ofNode>(ofNode*, void (ofNode::*)(ofQuaternion&), int)::'lambda'(void const*, ofQuaternion&), std::__1::allocator<std::__1::shared_ptr<of::priv::Function<ofQuaternion, std::__1::recursive_mutex> > ofEvent<ofQuaternion, std::__1::recursive_mutex>::make_function<ofNode>(ofNode*, void (ofNode::*)(ofQuaternion&), int)::'lambda'(void const*, ofQuaternion&)>, bool (void const*, ofQuaternion&)>::operator()(void const*&&, ofQuaternion&) (functional:1437)
14  Infinity                     
0x00000001003a3bfc std::__1::function<bool (void const*, ofEventArgs&)>::operator()(void const*, ofEventArgs&) const (functional:1817)
15  Infinity                     
0x00000001003a72a4 ofEvent<ofEventArgs, std::__1::recursive_mutex>::notify(void const*, ofEventArgs&) (ofEvent.h:136)
16  Infinity                     
0x00000001003a6b2c ofCoreEvents::notifySetup() (ofEvents.cpp:194)
17  Infinity                     
0x0000000100412318 -[ofxiOSEAGLView setup] (ofxiOSEAGLView.mm:103)
18  Foundation                   
0x0000000182e06658 __NSFireDelayedPerform + 428
19  CoreFoundation               
0x00000001823f5794 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 28
20  CoreFoundation               
0x00000001823f5438 __CFRunLoopDoTimer + 884
21  CoreFoundation               
0x00000001823f2b4c __CFRunLoopRun + 1520
22  CoreFoundation               
0x000000018231cc50 CFRunLoopRunSpecific + 384
23  GraphicsServices             
0x0000000183c04088 GSEventRunModal + 180
24  UIKit                       
0x00000001875fe088 UIApplicationMain + 204
25  Infinity                     
0x0000000100411294 ofAppiOSWindow::startAppWithDelegate(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) (ofAppiOSWindow.mm:131)
26  Infinity                     
0x00000001004111f8 ofAppiOSWindow::loop() (ofAppiOSWindow.mm:115)
27  Infinity                     
0x000000010040a2e0 ofMainLoop::loop() (ofMainLoop.cpp:126)
28  Infinity                     
0x00000001003a5664 ofRunApp(std::__1::shared_ptr<ofBaseApp>) (ofAppRunner.cpp:159)
29  Infinity                     
0x00000001003a55d0 ofRunApp(ofBaseApp*) (ofAppRunner.cpp:153)
30  Infinity                     
0x000000010001bef4 main (main.mm:21)
31  libdyld.dylib               
0x0000000181eba8b8 start + 4

Given the stack trace I would probably say that the first thing to look into is what is happening in -[PdPatch initWithFile:] and its descendents. There doesn't seem to be anything obvious that could be going wrong on the iOS side from here – the crashing code looks entirely like its your own (or at least provided by you, as Infinity isn't an Apple library).

But why would it behave differently with 64 bit than 32 bit?

I don't know what any of that code does, so I couldn't really tell you.

Actually, as I've noted, it's not that it doesn't work on 64 bit machines - it's that it doesn't work on 64 bit machines when the scheme is set to release. When set to debug it works fine. Given that, it seems more likely to be an issue with Xcode settings - and that's what I'm looking for help with.

I would think it's more likely an issue with your code, exposed by the different optimization settings for release builds. Impossible to say without seeing the code though.

junkpile, which optimization settings should I be looking at? And why would optimization settings be affecting 64 bit and not 32 bit? My current Optimization Level for Debug is None, and for Release is Fastets, Smallest - but I tried setting Release to None and that made no difference.

It's very likely that your bug is not deterministic, but is rather related to random details of execution timings and/or memory layouts. Both of those things are different when you change architectures or change optimization levels. The changes do not themselves introduce an error, they merely change run-time conditions so that an existing error is revealed.


The number one suspect in this kind of crash is a memory management bug. You have an idea where to look (in libpd, which I assume is your code, too), and what it's doing (loading data from a file?). So I suggest you poke around in the logic of that operation.


Also, based on the function names, it looks like you're loading numerical data, perhaps in vectors or arrays. Code like that is very prone to buffer overflow coding bugs, and those too will produce different failures depending on architecture or optimization. (In some cases, the overflow data might be written into an unused area at the end of a struct, which won't normally cause a crash.)


Finally, this is a very specific problem case, but it might apply if this code is Obj-C and using methods that return a struct (which seems possible if you're decoding structured numeric data). It is NOT safe to use such methods with a nil receiver, even though sending messages to nil is otherwise safe in Obj-C. The outcome of doing so is a random memory corruption, which may or may not cause a crash, depending what's overwritten. It's not likely that this is your problem, but it's worth thinking about, since I know from experience that it's a very difficult bug to find if you're not looking for it.

Thanks, QuincyMorris. libpd is not my code. It's this library: https://github.com/libpd/libpd

Yes, I guess it is loading data from a file - i.e. from a Pure Data file (e.g. ***.pd).


As I noted at the outset, 'I'm using Objective C and using ARC [for the main project], but I also have two sub-projects: libpd and OpenFrameworks, both of which have ARC turned off.' - would that cause problems?

As I noted at the outset, 'I'm using Objective C and using ARC [for the main project], but I also have two sub-projects: libpd and OpenFrameworks, both of which have ARC turned off.' - would that cause problems?

Not in and of itself. MRR and ARC code will happily coexist within a process as long as the MRR code follows the Cocoa memory management rules. Many of the Apple frameworks you use every day are MRR.

Getting back to your original problem, I suggest you investigate with Zombies (in case you have a memory management issue) or Address Sanitizer (in case you’re running off the end, or start, of a memory block).

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I tried Zombies and didn't discover anything with that tool (though admittedly I don't fully understand how to use it). I tried Address Sanitizer and got a BAD_ACCESS error that stopped on this code:



static void vline_tilde_dsp(t_vline *x, t_signal **sp)
{
    dsp_add(vline_tilde_perform, 3, x, sp[0]->s_vec, sp[0]->s_n);
    x->x_samppermsec = ((double)(sp[0]->s_sr)) / 1000;
    x->x_msecpersamp = ((double)1000) / sp[0]->s_sr;
}


Also, the sp variable repeatedly showed a value of NULL.

A quick ’net search reveals that this is part of libpd. You’re unlikely to find any libpd experts here. You can either investigate the code yourself or follow up with the support resources for that library.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Yes, things are pointing towards libpd, and I'm chasing it up with them.


Thanks