CODEWITHSUNDEEP
iphonexcode
Dan Selig
Dan Selig

Reputation: 264

iPhone app breaks in Release version not in Debug

I have a project in XCode 4.3.1 written for ARC so I do not mess with retain counts at all. When I run the project either in the simulator or on the device, it runs fine. If I run it under the profiler for allocations and leaks, it runs fine.

However, if I archive the project and distribute it for Ad Hoc and load the .ipa file, the app will crash with console messages:

<Notice>: Quilters_AppP(1812,0x3f85cd98) malloc: *** error for object 0x1109a910: pointer being freed was not allocated
<Notice>: *** set a breakpoint in malloc_error_break to debug

I set a breakpoint in malloc_error_debug but since the error occurs in the released version, I never see the debugger.

Here's where it gets really weird: Now that I have added some NSLog statements, the problem will not reproduce.

Here is the log:

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x00000000, 0x00000000
Crashed Thread:  0

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libsystem_kernel.dylib          0x34f5432c __pthread_kill + 8
1   libsystem_c.dylib               0x36e50208 pthread_kill + 48
2   libsystem_c.dylib               0x36e49298 abort + 88
3   libsystem_c.dylib               0x36e0437a free + 374
4   libobjc.A.dylib                 0x36583d72 object_dispose + 14
5   CoreFoundation                  0x350b6618 -[NSObject dealloc] + 76
6   CoreFoundation                  0x350b6736 -[__NSArrayI dealloc] + 162
7   libobjc.A.dylib                 0x3658316e _objc_rootRelease + 30
8   libobjc.A.dylib                 0x36584e50 objc_release + 32
9   libobjc.A.dylib                 0x36583ea6 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 218
10  libobjc.A.dylib                 0x36583dc2 _objc_autoreleasePoolPop + 6
11  CoreFoundation                  0x350b0cf8 _CFAutoreleasePoolPop + 12
12  UIKit                           0x3218ee34 _wrapRunLoopWithAutoreleasePoolHandler + 36
13  CoreFoundation                  0x35134b14 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 12
14  CoreFoundation                  0x35132d50 __CFRunLoopDoObservers + 252
15  CoreFoundation                  0x351330aa __CFRunLoopRun + 754
16  CoreFoundation                  0x350b649e CFRunLoopRunSpecific + 294
17  CoreFoundation                  0x350b6366 CFRunLoopRunInMode + 98
18  GraphicsServices                0x363b2432 GSEventRunModal + 130
19  UIKit                           0x321ace76 UIApplicationMain + 1074
20  Quilters_AppP                   0x0003505c main (main.m:17)
21  Quilters_AppP                   0x00034af4 0x33000 + 6900

Please help me catch this elusive bug. The app is targeted for 4.3/armv7.

Upvotes: 2

Views: 1185

Answers (4)

drewying
drewying

Reputation: 51

I had a similar problem. Your double loop described mine exactly. I had an array being defined nested between two while loops. In debug mode it was fine but when built for release it crashed with the exact same error.

Turns out that in Xcode 4.x.x you can add -O0 to the compiler flag of the file that is giving you problems (Under your project settings -> build phases -> compile sources) and it will turn off compiler optimization just for that single file. Worked like a charm for me.

Drew

Upvotes: 1

Dan Selig
Dan Selig

Reputation: 264

This is a compiler error; specifically in optimization. Code for testing is not optimized and code for release is optimized for "fastest, smallest". When I removed optimization for the release version, the problem went away.

The application code that triggered this is a managed object context access...

- (NSArray *) fetchForGroup:(Group *)group
{
    NSArray *array = [group.polygons allObjects];
    return array;
}

which is performed inside a double loop. When a condition is met in the inner loop, the function is exited via "return". The array from this call is double-freed. - Dan

Upvotes: 0

Dan Selig
Dan Selig

Reputation: 264

It seems that the problem was not in the application code but in the compiler code. The error must be either in the ARC pre-compiler or the compiler itself.

Upvotes: 0

hotpaw2
hotpaw2

Reputation: 70693

You can set breakpoints and debug an iOS app using the Project's Release Build settings (which are often quite different from the Debug Build settings). Just modify either your Build settings or your Run/Test Schemes to do so. Then clean, build and device debug.

Upvotes: 1

Related Questions