2

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.

4

2 回答 2

7

不幸的是，当代码抛出异常时，try-catch 框架会很好，但对“信号”没有帮助。（“SIGSEGV”中的“SIG”表示它是一个信号。）

为了处理信号，您必须为您的应用程序指定一个信号处理程序，该处理程序将在触发信号时由系统调用。

在堆栈以 objc_msgSend 结尾的任何类型的 SIGSEGV 的情况下，您很可能有代码试图调用已释放对象的方法。

在设备上，您可以在启用“NSZombies”的情况下运行以提供帮助。当您尝试向它们发送消息时，这将保留少量对象以引发异常。

堆栈在 objc_msgSend 结束时可能会被奇怪地修改，因此实际问题点可能与您在崩溃日志堆栈中看到的不同。

于 2013-01-25T00:31:33.263 回答
0

你调查过 NSSetUncaughtExceptionHandler 吗？您还可以使用信号函数将信号（例如 SIGSEGV）映射到处理函数

于 2012-09-12T08:51:18.480 回答