Will @try @catch work for SIGSEGV / SEGV_ACCERR

I have a crash in a third party component. It is clear that there is an underlying cause for this which I have to research. But to make this more robust in the meantime I want to surround the crashing call with a @try @catchblock.

I could not reproduce the crash so far so I can't really tell if the @try @catch will work in this case. My question in what type of cases does @try and @catch generally work.

Hardware Model:      iPhone3,1
Process:         MyApp [2084]
Path:            /var/mobile/Applications/8B400A7D-88E7-4319-9C5D-F7E72DE8D960/MyApp.app/MyApp
Identifier:      com.company.MyApp-Snapshot
Version:         7.2
Code Type:       ARM
Parent Process:  launchd [1]

Date/Time:       2012-09-07 14:04:14 +0000
OS Version:      iPhone OS 5.1.1 (9B206)
Report Version:  104

Exception Type:  SIGSEGV
Exception Codes: SEGV_ACCERR at 0xe1088602
Crashed Thread:  0

Thread 0 Crashed:
0   libobjc.A.dylib    0x35260f78 objc_msgSend + 15
1   UIKit              0x312363d7 -[UIView(Hierarchy) superview] + 50
***************************************************************************                     |<---- UIView *superview = self.superview;
2   MyApp              0x000238f9 -[MBProgressHUD deviceOrientationDidChange:] (MBProgressHUD.m:622)
***************************************************************************
3   Foundation         0x37dc64ff __57-[NSNotificationCenter addObserver:selector:name:object:]_block_invoke_0 + 18
4   CoreFoundation     0x3752d547 ___CFXNotificationPost_block_invoke_0 + 70
5   CoreFoundation     0x374b9097 _CFXNotificationPost + 1406
6   Foundation         0x37d3a3eb -[NSNotificationCenter postNotificationName:object:userInfo:] + 66
7   UIKit              0x3123adeb -[UIDevice setOrientation:animated:] + 214
8   UIKit              0x3123616f -[UIApplication handleEvent:withNewEvent:] + 2718
9   UIKit              0x31235567 -[UIApplication sendEvent:] + 54
10  UIKit              0x31234f3b _UIApplicationHandleEvent + 5826
11  GraphicsServices   0x33c7722b PurpleEventCallback + 882
12  CoreFoundation     0x37535523 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 38
13  CoreFoundation     0x375354c5 __CFRunLoopDoSource1 + 140
14  CoreFoundation     0x37534313 __CFRunLoopRun + 1370
15  CoreFoundation     0x374b74a5 CFRunLoopRunSpecific + 300
16  CoreFoundation     0x374b736d CFRunLoopRunInMode + 104
17  GraphicsServices   0x33c76439 GSEventRunModal + 136
18  UIKit              0x31263cd5 UIApplicationMain + 1080
19  MyApp              0x00003643 main (main.m:16)

Update: Apparently SIGSEGV is not an exception that you can catch but caused by accessing memory which is not valid. From my perspective it would still be convenient to be able to catch this sort of exception, although getting the root of the problem was obviously the better approach to fix the problem.

Unfortunately, a try-catch frame will be good when code throws an exception, but will not help with a "signal". (The "SIG" in "SIGSEGV" means it was a signal.)

For dealing with signals, you must specify a signal handler for your application which will be called by the system when a signal is fired.

In the case of any type of SIGSEGV where the stack ends in objc_msgSend, you very likely have code trying to call a method of a released object.

On a device you can run with "NSZombies" enabled to help. This will keep small bits of objects around to throw exceptions when you try send messages to them.

The stack can be modified strangely when it ends in objc_msgSend, so the actual problem point may be different than you see in the crash log stacks.