I am clearly missing something obvious here and would really appreciate some input. I have tried repeatedly to submit an application to Apple (iPad in this case) that is crashing on their end when testing but I cannot replicated the situation on my end (obviously I only have the damned simulator to work with at this point).
The crash log is as follows:
Date/Time: 2010-04-01 05:39:47.226 -0700
OS Version: iPhone OS 3.2 (7B367)
Report Version: 104
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x00000000, 0x00000000
Crashed Thread: 0
Thread 0 Crashed:
0 libSystem.B.dylib 0x000790a0 __kill + 8
1 libSystem.B.dylib 0x00079090 kill + 4
2 libSystem.B.dylib 0x00079082 raise + 10
3 libSystem.B.dylib 0x0008d20a abort + 50
4 libstdc++.6.dylib 0x00044a1c __gnu_cxx::__verbose_terminate_handler() + 376
5 libobjc.A.dylib 0x000057c4 _objc_terminate + 104
6 libstdc++.6.dylib 0x00042dee __cxxabiv1::__terminate(void (*)()) + 46
7 libstdc++.6.dylib 0x00042e42 std::terminate() + 10
8 libstdc++.6.dylib 0x00042f12 __cxa_throw + 78
9 libobjc.A.dylib 0x000046a4 objc_exception_throw + 64
10 CoreFoundation 0x00090c6e +[NSException raise:format:arguments:] + 74
11 CoreFoundation 0x00090d38 +[NSException raise:format:] + 28
12 Foundation 0x00002600 -[NSCFDictionary setObject:forKey:] + 184
13 iPadMosaic 0x00003282 -[iPadMosaicViewController getAlbumThumbs] (iPadMosaicViewController.m:468)
14 Foundation 0x000728fe __NSFireDelayedPerform + 314
15 CoreFoundation 0x00022d1c CFRunLoopRunSpecific + 2092
16 CoreFoundation 0x000224da CFRunLoopRunInMode + 42
17 GraphicsServices 0x000030d4 GSEventRunModal + 108
18 GraphicsServices 0x00003180 GSEventRun + 56
19 UIKit 0x000034c2 -[UIApplication _run] + 374
20 UIKit 0x000019ec UIApplicationMain + 636
21 iPadMosaic 0x00002234 main (main.m:14)
22 iPadMosaic 0x00002204 start + 32
My understanding here is that I am botching the Dictionary add somehow. The relevant lines of code are:
for (NSDictionary *album in self.albumList) {
// Get image for each album cover
UIImage *albumCover;
// Loop through photos to get URL of cover based on photo ID match
NSString *coverURL = #"";
for (NSDictionary *photo in self.photoList) {
if ([[photo objectForKey:#"pid"] isEqualToString:[album objectForKey:#"cover_pid"]]) {
coverURL = [photo objectForKey:#"src"];
}
}
NSURL *albumCoverURL = [NSURL URLWithString:coverURL];
NSData *albumCoverData = [NSData dataWithContentsOfURL:albumCoverURL];
albumCover = [UIImage imageWithData:albumCoverData];
if (albumCover == nil || albumCover == NULL) {
//NSLog(#"No album cover for some reason");
albumCover = [UIImage imageNamed:#"noImage.png"];
}
[[self.albumList objectAtIndex:albumCurrent] setObject:albumCover forKey:#"coverThumb"];
}
This is part of a loop that runs over the existing dictionaries stored in an array. If retrieving the album cover fails for some reason the object is filled with a default image and then added. The last line of the code is what's showing up in the crash log.
It runs fine in the simulator but crashes 100% in testing on device apparently. Can anyone tell me what I am missing here?
If Foundation isn't radically changed in from 3.0 to 3.2, then there's only 3 cases an exception is raised in -setObject:forKey::
mutating method sent to immutable object
attempt to insert nil value
attempt to insert nil key
Obviously the 3rd case is impossible, so you only need to check:
Is [self.albumList objectAtIndex:albumCurrent] guaranteed to be an NSMutableDictionary?
Have you forgotten to include noImage.png in submission?
I had the same problem! It was a case sensitivity issue...make sure that the file named noImage.png matches the actual file...not NoImage.png or noimage.png...check all of your images! I missed out on the app store opening because of 1 letter on 1 file!
Related
If an unhandled NSException is thrown, the stack trace has a section like this:
Last Exception Backtrace:
0 CoreFoundation 0x32bd688f __exceptionPreprocess + 163
1 libobjc.A.dylib 0x34b7b259 objc_exception_throw + 33
2 CoreFoundation 0x32bd65c5 -[NSException init] + 1
3 Foundation 0x37296bd7 -[NSObject(NSKeyValueCoding) valueForUndefinedKey:] + 263
...
But if std::exception is thrown, I get only this:
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x34f2632c __pthread_kill + 8
1 libsystem_c.dylib 0x31e4c208 pthread_kill + 48
2 libsystem_c.dylib 0x31e45298 abort + 88
3 libc++abi.dylib 0x33bcaf64 abort_message + 40
4 libc++abi.dylib 0x33bc8346 default_terminate() + 18
5 libobjc.A.dylib 0x349f4368 _objc_terminate + 164
6 libc++abi.dylib 0x33bc83be safe_handler_caller(void (*)()) + 70
7 libc++abi.dylib 0x33bc844a std::terminate() + 14
8 libc++abi.dylib 0x33bc981e __cxa_rethrow + 82
9 libobjc.A.dylib 0x349f42a2 objc_exception_rethrow + 6
10 CoreFoundation 0x329a5506 CFRunLoopRunSpecific + 398
11 CoreFoundation 0x329a5366 CFRunLoopRunInMode + 98
12 GraphicsServices 0x32af2432 GSEventRunModal + 130
13 UIKit 0x34f84cce UIApplicationMain + 1074
14 APP_NAME 0x00086b10 main (main.m:68)
15 APP_NAME 0x00071b98 start + 32
How do I get the exact crash info from this crash log?
Update --
I've given HockeyApp a shot, but it has the same limitation as iTunes crash logs - it doesn't tell me the stack for an unhandled C++ exception.
What you're seeing is an unfortunate quirk of AppKit and UIKit. Both iOS and OS X have an exception handler in CFRunLoop that traps all uncaught exceptions. On OS X, the handler displays the exception to the user with a dialog box, but on iOS, the handler simply rethrows the exception.
Objective-C exceptions, as implemented by NSException, save their backtraces within the exception object right before the actual "throw" happens, as part of [NSException init] (or a similar initializer method). Unfortunately, C++ exceptions don't do the same. Normally, a C++ exception has a backtrace because the runtime library detects that there's no catch and immediately calls std::terminate, which in turn calls abort(), leaving the entire call stack intact, like so:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff93ef8d46 __kill + 10
1 libsystem_c.dylib 0x00007fff89968df0 abort + 177
2 libc++abi.dylib 0x00007fff8beb5a17 abort_message + 257
3 libc++abi.dylib 0x00007fff8beb33c6 default_terminate() + 28
4 libobjc.A.dylib 0x00007fff8a196887 _objc_terminate() + 111
5 libc++abi.dylib 0x00007fff8beb33f5 safe_handler_caller(void (*)()) + 8
6 libc++abi.dylib 0x00007fff8beb3450 std::terminate() + 16
7 libc++abi.dylib 0x00007fff8beb45b7 __cxa_throw + 111
8 test 0x0000000102999f3b main + 75
9 libdyld.dylib 0x00007fff8e4ab7e1 start + 1
However, when the run loop exception handler traps the exception, execution resumes normally within the catch block. The original backtrace is therefore lost. The rethrow subsequently calls std::terminate, but at this point, the call stack reflects the run loop exception handler.
To get a backtrace from a C++ exception in this circumstance, you have to throw an exception object which mimics NSException and reads the call stack as part of its constructor, and make sure that all exceptions thrown in your code do the same. std::exception doesn't do this, and it's not at all likely that any third-party code you're using will either.
File a bug with Apple asking them to remove the CFRunLoop exception handler, or at least provide an API for shutting it off. There is no API, not even an SPI, for doing this right now.
I've had luck with improving mpipe3's answer.
In my main method, I use a try-catch to get the C++ exception and then call a dispatch_sync on dispatch_get_global_queue. Now the full stack trace with line numbers will show on Crashlytics (crash manager).
int main(int argc, char *argv[]) {
#autoreleasepool {
#try{
return UIApplicationMain(argc, argv, nil, #"AppControllerClassName");
} #catch (NSException *exception) {/* Catch any uncaught exceptions and print out a friendly call stack. Instead of an ugly memory addresses. */
NSString * message = [NSString stringWithFormat:#"Uncaught exception %# : %#\n %#", exception.name, exception.reason, [exception callStackSymbols]];
[LogManager e:#"main.m" Message:message Exception: exception];
#throw;
} #catch (...){
//Attempt to get the correct stacktrace for C++ exceptions.
dispatch_sync(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
#throw;
});
}
return 0;
}
}
This works as it avoids the CFRunLoop exception handler by using GCD to throw the exception.
Following on from Gwynne Raskind answer you can avoid the CFRunLoop exception handler by using GCD to dispatch a call to a block of C++ code synchronously:
namespace
{
void MyThrowingCode()
{
throw std::runtime_error("My Exception");
}
}
- (void)objcHandlerCalledFromARunLoop
{
dispatch_sync(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
MyThrowingCode();
});
}
You might need to create your own queues rather than using a single shared queue.
The crash log looks like this:
0 libsystem_kernel.dylib 0x3aa39350 __pthread_kill + 8
1 libsystem_c.dylib 0x3a9affb2 pthread_kill + 54
2 libsystem_c.dylib 0x3a9ec366 abort + 90
3 libc++abi.dylib 0x39f94dda abort_message + 70
4 libc++abi.dylib 0x39f92094 default_terminate() + 20
5 libobjc.A.dylib 0x3a545a70 _objc_terminate() + 168
6 libc++abi.dylib 0x39f92118 safe_handler_caller(void (*)()) + 76
7 libc++abi.dylib 0x39f921b0 std::terminate() + 16
8 libc++abi.dylib 0x39f9359a __cxa_throw + 118
9 Test 0x000fddfc MyThrowingCode() (MainViewController.mm:177)
10 Test 0x000fe38c __35-[MainViewController toolsClick:]_block_invoke (MainViewController.mm:184)
11 libdispatch.dylib 0x3a95f5d8 _dispatch_client_callout + 20
12 libdispatch.dylib 0x3a962776 _dispatch_sync_f_invoke + 22
13 Test 0x000fde90 -[MainViewController toolsClick:] (MainViewController.mm:183)
14 UIKit 0x34744082 -[UIApplication sendAction:to:from:forEvent:] + 66
15 UIKit 0x3474410c -[UIBarButtonItem(UIInternal) _sendAction:withEvent:] + 116
16 UIKit 0x34744082 -[UIApplication sendAction:to:from:forEvent:] + 66
17 UIKit 0x34744036 -[UIApplication sendAction:toTarget:fromSender:forEvent:] + 26
18 UIKit 0x34744010 -[UIControl sendAction:to:forEvent:] + 40
19 UIKit 0x347438c6 -[UIControl(Internal) _sendActionsForEvents:withEvent:] + 498
20 UIKit 0x34743db4 -[UIControl touchesEnded:withEvent:] + 484
21 UIKit 0x3466c5f4 -[UIWindow _sendTouchesForEvent:] + 520
22 UIKit 0x346598dc -[UIApplication sendEvent:] + 376
23 UIKit 0x346591ea _UIApplicationHandleEvent + 6194
24 GraphicsServices 0x363715f4 _PurpleEventCallback + 588
25 GraphicsServices 0x36371222 PurpleEventCallback + 30
26 CoreFoundation 0x3281f3e4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 32
27 CoreFoundation 0x3281f386 __CFRunLoopDoSource1 + 134
28 CoreFoundation 0x3281e20a __CFRunLoopRun + 1378
29 CoreFoundation 0x32791238 CFRunLoopRunSpecific + 352
30 CoreFoundation 0x327910c4 CFRunLoopRunInMode + 100
31 GraphicsServices 0x36370336 GSEventRunModal + 70
32 UIKit 0x346ad2b4 UIApplicationMain + 1116
33 Test 0x00120462 main (main.mm:55)
34 libdyld.dylib 0x3a972b1c start + 0
looks like the exception is happening from inside UIApplicationMain()... You could try converting your main.m file to a main.mm file, and doing this:
int main(...)
{
try
{
return UIApplicationMain(...);
}
catch( exception e )
{
cerr < e.what() ;
}
}
I didn't actually try it, however...
I'm getting a strange crash when using NSFileManager to get the file size in a background thread.
I have a property of a song object called localFileSize:
- (unsigned long long)localFileSize
{
return [[[NSFileManager defaultManager] attributesOfItemAtPath:self.currentPath error:NULL] fileSize];
}
In my class that handles my audio playback (using a 3rd party audio library, not AQS or Core Audio), there is a file length callback function that is called in the audio library's playback thread, so not the main thread.
In that file length function, I'm reading the localFileSize property of my song object, inside an #autoreleasepool. At the end of the function, when the pool is drained, there appears to sometimes be a crash with the NSFileAttributes object's dealloc method. I can't reproduce it myself, but I have 14 crash logs with this issue.
Here is the relevant portion of one of the crash logs:
Thread 8 Crashed:
0 libobjc.A.dylib 0x3262c4e8 _ZN4objc8DenseMapIP11objc_objectmLb1ENS_12DenseMapInfoIS2_EENS3_ImEEE4growEj + 67
1 libobjc.A.dylib 0x32638d81 _ZN4objc8DenseMapIP11objc_objectmLb1ENS_12DenseMapInfoIS2_EENS3_ImEEE16InsertIntoBucketERKS2_RKmPSt4pairIS2_mE + 56
2 libobjc.A.dylib 0x3262b09d _ZN4objc8DenseMapIP11objc_objectmLb1ENS_12DenseMapInfoIS2_EENS3_ImEEE16FindAndConstructERKS2_ + 44
3 libobjc.A.dylib 0x3262b139 _objc_rootReleaseWasZero + 92
4 libobjc.A.dylib 0x3262b0ad _objc_rootRelease + 12
5 Foundation 0x31fbab81 -[NSFileAttributes dealloc] + 60
6 libobjc.A.dylib 0x3262b0c5 _objc_rootRelease + 36
7 libobjc.A.dylib 0x3262cdb7 objc_release + 38
8 libobjc.A.dylib 0x3262be0d _ZN12_GLOBAL__N_119AutoreleasePoolPage3popEPv + 224
9 libobjc.A.dylib 0x3262bd29 _objc_autoreleasePoolPop + 12
10 CoreFoundation 0x35b0ce8f _CFAutoreleasePoolPop + 18
11 Foundation 0x31f8aaf1 -[NSAutoreleasePool drain] + 128
12 iSub 0x000fb6cb MyFileLenProc (AudioEngine.m:320)
13 iSub 0x001623d8 BASS_FX_TempoCreate + 5160
14 iSub 0x0016261c BASS_FX_TempoCreate + 5740
15 iSub 0x0017f42c BASS_ChannelIsActive + 27424
16 AudioToolbox 0x364905d9 _ZN19AudioConverterChain19DirectCallInputProcEPmS0_P15AudioBufferListPPK28AudioStreamPacketDescription + 228
17 AudioToolbox 0x36465ee3 _ZN14CodecConverter13CallInputProcERm + 266
18 AudioToolbox 0x3646588d _ZN14CodecConverter17DecoderFillBufferERmR15AudioBufferListP28AudioStreamPacketDescription + 576
19 AudioToolbox 0x36465649 _ZN14CodecConverter10FillBufferERmR15AudioBufferListP28AudioStreamPacketDescription + 28
20 AudioToolbox 0x36452c99 _ZN19AudioConverterChain12RenderOutputEP12CABufferListmRmP28AudioStreamPacketDescription + 92
21 AudioToolbox 0x36452b53 _ZN22BufferedAudioConverter10FillBufferERmR15AudioBufferListP28AudioStreamPacketDescription + 186
22 AudioToolbox 0x36452929 AudioConverterFillComplexBuffer + 356
23 iSub 0x0017d9f8 BASS_ChannelIsActive + 20716
24 iSub 0x00184f70 BASS_ChannelSetPosition + 640
25 iSub 0x00186eb4 BASS_ChannelGetData + 1032
26 iSub 0x000fc787 __35-[AudioEngine keepRingBufferFilled]_block_invoke_0 (AudioEngine.m:752)
27 libdispatch.dylib 0x35e3fd55 _dispatch_call_block_and_release + 12
28 libdispatch.dylib 0x35e4b7a3 _dispatch_worker_thread2 + 262
29 libsystem_c.dylib 0x30fbb1cf _pthread_wqthread + 294
Any ideas what could be causing this?
Also, if it makes any difference, at the time these crashes were reported the project was not using ARC. I recently converted to ARC, but have not released the update yet. I don't that would make any difference in this case though anyway.
Also, it's worth noting that all of the crash reports have been from iOS 5.0.1 and 5.1, even though my app supports 4.2 and above. So potentially an iOS 5 bug of some kind?
I wonder when did that change? I clearly remember [NSFileManager defaultManager] not being thread-safe. And, by the way, we are having the same issue calling defaultManager from multiple threads as well. It looks like other people remember it the same way: http://useyourloaf.com/blog/2011/06/12/nsfilemanager-defaultmanager-is-not-thread-safe.html
Don't use the +defaultManager from background threads. Just alloc+init an instance, use it, and (if not using ARC) release it. That was just wrong.
Ended up using something like this to get file size:
#include <sys/stat.h>
struct stat fileInfo;
off_t fileSize; // Can cast to long long
stat(filename, &fileInfo);
fileSize = fileInfo.st_size;
Or you can try creating new NSFileManager objects, as it appears the docs may not be completely truthful about thread safety.
Hullo,
I am experimenting a very vicious crash that shows up in the following way in the device logs:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x50000008
Crashed Thread: 0`
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x33b24c98 objc_msgSend + 16
1 Foundation 0x3429465a _NSURLConnectionReleaseClient + 30
2 CFNetwork 0x355ac608 ClientContextHolder<CFURLConnectionClient_V4>::forget() + 20
3 CFNetwork 0x355ac5ea URLConnectionClient::releaseClientLocked() + 34
4 CFNetwork 0x355a0e9a URLConnectionClient::processEvents() + 170
5 CFNetwork 0x355a0de2 URLConnection::multiplexerClientPerform(RunLoopMultiplexer*) + 30
6 CFNetwork 0x355a0d54 MultiplexerSource::perform() + 120
7 CFNetwork 0x355a0cd2 MultiplexerSource::_perform(void*) + 2
8 CoreFoundation 0x3039ca72 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 6
9 CoreFoundation 0x3039e758 __CFRunLoopDoSources0 + 376
10 CoreFoundation 0x3039f4e4 __CFRunLoopRun + 224
11 CoreFoundation 0x3032febc CFRunLoopRunSpecific + 224
12 CoreFoundation 0x3032fdc4 CFRunLoopRunInMode + 52
13 GraphicsServices 0x35571418 GSEventRunModal + 108
14 GraphicsServices 0x355714c4 GSEventRun + 56
15 UIKit 0x358c7d62 -[UIApplication _run] + 398
16 UIKit 0x358c5800 UIApplicationMain + 664
17 inArrivo 0x000023ca main (main.m:14)
18 inArrivo 0x00002394 start + 32
After having enabled NSZombie I also have a crash on the compiler log of the following form:
2011-05-09 16:12:24.400 inArrivo[5019:707] * -[NSURLConnection releaseDelegate]: message sent to deallocated instance 0x5d61670
appearing on the app main with the last NSLog comeing from a function with no url connections. Also if I remove some pieces of very innocent code from that function, no crash occurs, and the same happens when I run the complete application on the simulator.
Could someone give me some hints about what I may do to locate the piece of code producing the crash? Normal debugging of course is of little help here.
Thanks,
Fabrizio Bartolomucci
The message indicates that the delegate for NSURLConnection was deallocated. I would suggest you check the delegate object to see if you are doing an extra release on it.
My app was rejected from the app store due to a crash that produced the crash log below. What is even more strange than the crash is that the steps given to reproduce it don't happen to me or any of 10+ beta testers (on differing iOS devices). Can anyone help explain this more? I know the exception codes are some sort of memory thing, but is that the only reason that could cause this crash log? For instance, I don't even get a line number.
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x00000000, 0x00000000
Crashed Thread: 0
Thread 0 Crashed:
0 libSystem.B.dylib 0x33bd52d4 __kill + 8
1 libSystem.B.dylib 0x33bd52c4 kill + 4
2 libSystem.B.dylib 0x33bd52b6 raise + 10
3 libSystem.B.dylib 0x33be9d72 abort + 50
4 libstdc++.6.dylib 0x31bdba20 __gnu_cxx::__verbose_terminate_handler() + 376
5 libobjc.A.dylib 0x3347c594 _objc_terminate + 104
6 libstdc++.6.dylib 0x31bd9df2 __cxxabiv1::__terminate(void (*)()) + 46
7 libstdc++.6.dylib 0x31bd9e46 std::terminate() + 10
8 libstdc++.6.dylib 0x31bd9f16 __cxa_throw + 78
9 libobjc.A.dylib 0x3347b4c4 objc_exception_throw + 64
10 Foundation 0x33639910 __NSThreadPerformPerform + 648
11 CoreFoundation 0x33a767d6 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 6
12 CoreFoundation 0x33a485b0 __CFRunLoopDoSources0 + 376
13 CoreFoundation 0x33a47e54 __CFRunLoopRun + 224
14 CoreFoundation 0x33a47c80 CFRunLoopRunSpecific + 224
15 CoreFoundation 0x33a47b88 CFRunLoopRunInMode + 52
16 GraphicsServices 0x33b0e4a4 GSEventRunModal + 108
17 GraphicsServices 0x33b0e550 GSEventRun + 56
18 UIKit 0x32099322 -[UIApplication _run] + 406
19 UIKit 0x32096e8c UIApplicationMain + 664
20 AppName 0x00002172 main (main.m:14)
21 AppName 0x0000213c start + 32
Your code threw an un-handled exception somewhere or called abort() for some reason. It looks like it's happening in a dispatch to the main thread (so somewhere you are calling something like [obj performSelectorOnMainThread:#selector(something:) withObject:nil] or something similar. My best guess is that the selector you're choosing doesn't exist on the object (either due to memory management issues, like the object was replaced by something else) or due to some dynamic assignment you're doing.
I have an app that only crashes for one of my tester’s - no one else’s. But it crashes consistently for her. It’s very odd.
Details:
She has in iPhone 4 and an iPhone 3Gs
The app crashes on all OSes on BOTH phones
The app crashes with all contacts no matter how they were created
When she sends me her contacts they work fine on both my iPHone 4 and my 3G (not s)
She is the ONLY one that ever gets a crash and it is consistent across both phones and all OSes
She has uninstalled and reinstalled the app and the provisioning profile
She is syncing her iPhone with a windows machine version of iTunes
The crash happens when we use ABPeoplePicker.
From her perspective it looks like the minute she selects a phone number the app crashes.
Of course she is not in our app at that moment. She is in the ABPeoplePicker navigation view provided by Apple.
From the resymbolicated crash log it looks to me like it’s actually crashing when it is trying to return to our app. In other words I can’t find any mention of our app actually being responsible for the crash in the crash log (see below).
It looks like it’s not able to get the index of the selected phone number and then fails when trying to pop back into our app but that’s a guess at best.
I have read the Apple docs and tried to do due diligence in learning about how to read crash logs but I am still stumped.
Here are my questions:
1. Does anyone know what Exception Codes: 0x00000000, 0x00000000 means?
2. Am I correct in assuming that line 9 is where the actual issues is referred to? And if so how do I understand what objc_exception_throw + 64 means?
3. Can anyone shed some light on what this crash log says the problem is?
Incident Identifier:
CrashReporter Key:
Hardware Model: iPhone3,1
Process: My App [471]
Path:
Identifier: My App
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2010-12-06 16:32:44.088 -0600
OS Version: iPhone OS 4.0.2 (8A400)
Report Version: 104
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x00000000, 0x00000000
Crashed Thread: 0
Thread 0 Crashed:
0 libSystem.B.dylib 0x000791d0 __kill + 8
1 libSystem.B.dylib 0x000791c0 kill + 4
2 libSystem.B.dylib 0x000791b2 raise + 10
3 libSystem.B.dylib 0x0008d6fa abort + 50
4 libstdc++.6.dylib 0x00044a20 __gnu_cxx::__verbose_terminate_handler() + 376
5 libobjc.A.dylib 0x000059ec _objc_terminate + 104
6 libstdc++.6.dylib 0x00042df2 __cxxabiv1::__terminate(void (*)()) + 46
7 libstdc++.6.dylib 0x00042e46 std::terminate() + 10
8 libstdc++.6.dylib 0x00042f16 __cxa_throw + 78
9 libobjc.A.dylib 0x000048cc objc_exception_throw + 64
10 CoreFoundation 0x0001fb72 -[__NSArrayI objectAtIndex:] + 154
11 My App 0x00005a68 0x1000 + 19048
12 My App 0x00005dec 0x1000 + 19948
13 UIKit 0x000668f4 -[UIViewController view] + 104
14 UIKit 0x000784e4 -[UIViewController contentScrollView] + 16
15 UIKit 0x00078354 -[UINavigationController _computeAndApplyScrollContentInsetDeltaForViewController:] + 24
16 UIKit 0x00078252 -[UINavigationController _layoutViewController:] + 18
17 UIKit 0x00077d58 -[UINavigationController _startTransition:fromViewController:toViewController:] + 372
18 UIKit 0x00077b68 -[UINavigationController _startDeferredTransitionIfNeeded] + 176
19 UIKit 0x00066fa8 -[UINavigationController pushViewController:transition:forceImmediate:] + 600
20 UIKit 0x00066d40 -[UINavigationController pushViewController:animated:] + 28
21 My App 0x0000a29a 0x1000 + 37530
22 My App 0x0000bcba 0x1000 + 44218
23 AddressBookUI 0x00032cfc -[ABPeoplePickerNavigationController personViewController:shouldPerformDefaultActionForPerson:property:identifier:withMemberCell:] + 152
24 AddressBookUI 0x0003b8ce -[ABPersonViewControllerHelper personTableViewDataSource:selectedPropertyAtIndex:inPropertyGroup:withMemberCell:forEditing:] + 222
25 AddressBookUI 0x0004a17c -[ABPersonTableViewDataSource valueAtIndex:selectedForPropertyGroup:withMemberCell:forEditing:] + 40
26 AddressBookUI 0x00048c00 -[ABPersonTableViewDataSource tableView:didSelectRowAtIndexPath:] + 316
27 UIKit 0x00091f40 -[UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:] + 656
28 UIKit 0x0009db40 -[UITableView _userSelectRowAtIndexPath:] + 124
29 Foundation 0x00086c86 __NSFireDelayedPerform + 362
30 CoreFoundation 0x00071a54 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 8
31 CoreFoundation 0x00073ede __CFRunLoopDoTimer + 854
32 CoreFoundation 0x0007485e __CFRunLoopRun + 1082
33 CoreFoundation 0x0001d8e4 CFRunLoopRunSpecific + 224
34 CoreFoundation 0x0001d7ec CFRunLoopRunInMode + 52
35 GraphicsServices 0x000036e8 GSEventRunModal + 108
36 GraphicsServices 0x00003794 GSEventRun + 56
37 UIKit 0x000062a0 -[UIApplication _run] + 396
38 UIKit 0x00004e10 UIApplicationMain + 664
39 My App 0x0000d694 0x1000 + 50836
40 My App 0x00002d00 0x1000 + 7424
Here is my ABPeoplePicker code.
#pragma mark ABPeoplePickerNavigationControllerDelegate methods
// Displays the information of a selected person
- (BOOL)peoplePickerNavigationController:(ABPeoplePickerNavigationController *)peoplePicker shouldContinueAfterSelectingPerson:(ABRecordRef)person
{
return YES;
}
// Does not allow users to perform default actions such as dialing a phone number, when they select a person property.
- (BOOL)peoplePickerNavigationController:(ABPeoplePickerNavigationController *)peoplePicker
shouldContinueAfterSelectingPerson:(ABRecordRef)person
property:(ABPropertyID)property
identifier:(ABMultiValueIdentifier)identifier {
CFStringRef cfName = ABRecordCopyCompositeName(person);
self.selectedName = [NSString stringWithString:(NSString *)cfName];
CFRelease(cfName);
ABMultiValueRef allThePhoneNums = ABRecordCopyValue(person, kABPersonPhoneProperty);
// ABMultiValueGetIndexForIdentifier the exact value of the "identifier" passed to us.
NSString *number = (NSString *)ABMultiValueCopyValueAtIndex(allThePhoneNums, ABMultiValueGetIndexForIdentifier(allThePhoneNums, identifier));
self.selectedNumber = number;
[number release];
CFRelease(allThePhoneNums);
[self showDialOutToPartViewControllerWithName:self.selectedName andNumber:self.selectedNumber];
[peoplePicker dismissModalViewControllerAnimated:YES];
return NO;
}
// Dismisses the people picker and shows the application when users tap Cancel.
- (void)peoplePickerNavigationControllerDidCancel:(ABPeoplePickerNavigationController *)peoplePicker; {
[self dismissModalViewControllerAnimated:YES];
}
Foremost, it helps to symbolicate your crash logs using the symbolicatecrash tool and the DSYM file that was generated when you compiled it. I won't discuss how to do that here -- you can search Google to find more details; try "symbolicate crash log DSYM" as keywords.
Once you do that, instead of:
My App 0x0232032+433
It will show something like this:
My App [className callSomeMethod:argument]
Much easier to find the line of code that is spawning the problem.
However - note in the stack trace that the last line of code is [array objectAtIndex:] in Foundation. This method will throw an NSRangeException when you pass an index outside of the bounds of the receiver (e.g. array). From the NSArray docs:
If index is beyond the end of the
array (that is, if index is greater
than or equal to the value returned by
count), an NSRangeException is raised.
So, I'd put my money on that being your crash.
Then the question is - after you symbolicate your crash log - what line of your code is calling an array with an out-of-bounds index?