How did I crash in a @try/@catch block?

Question

I received the following crash report (truncated)

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

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libsystem_kernel.dylib          0x36df00d8 __psynch_mutexwait + 24
1   libsystem_c.dylib               0x31760674 pthread_mutex_lock + 376
2   CoreFoundation                  0x31f2338a CFRunLoopWakeUp + 50
3   WebCore                         0x308d0bc8 _WebThreadRun + 284
4   UIKit                           0x37921c7a -[UIWebDocumentView _runLoadBlock:] + 38
5   UIKit                           0x37921c3a -[UIWebDocumentView _cleanUpFrameStateAndLoad:] + 114
6   UIKit                           0x37921bbe -[UIWebDocumentView loadHTMLString:baseURL:] + 78

The concern is that the calling code looks like this:

@try {
    [webView loadHTMLString:htmlString baseURL:nil];
    [webView setNeedsDisplay];     
}
@catch (NSException *exception) {...}

So, how did I manage to throw an exception from within an exception handler?

I didn't call the throwing method from inside catch. All I'm doing there is dumping to NSLog the exception, the webView, and the htmlString. If they were causing the exception I would expect the crash stack to look differently.

Does this seem to reduce into a potential OS bug?

Answer 1

This is a segmentation fault (SIGSEGV), not an exception.

Those faults aren't exceptions, meaning you can't use a try/catch block.

A segmentation fault means you are trying to access a memory region that doesn't belong to your app.

In your case, it may be cause be auto-released objects that gets deallocated, and then accessed (the pointer is not valid anymore, since the object was deallocated).

Ensure your htmlString variable is still pointing to a valid object...

By the way, I don't think calling setNeedsDisplay is needed after using loadHTMLString.