Stack crashing on internal methods, only happens sometimes (race condition?) and only in simulator

Question

I've been trying to track down the cause of this crash, it happens quite frequently, but only in simulator (not on device), and then only part of the time.

Stack Trace is:

I'm calling:

UITextView *myTextView = [[UITextView alloc] initWithFrame:CGRectMake(0,0,100,100)];

And in most situations there is no problem here. The really frustrating part is that it is not having issue with what I'm calling, but instead some issue in WebFrame internals (which I assume is an internal piece of UITextView

Crashlog:

2011-04-18 14:34:48.729 MyApp[73336:40b] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[WebFrame _isIncludedInWebKitStatistics]: unrecognized selector sent to instance 0xa901a50'
*** Call stack at first throw:
(
    0   CoreFoundation                      0x03003be9 __exceptionPreprocess + 185
    1   libobjc.A.dylib                     0x031585c2 objc_exception_throw + 47
    2   CoreFoundation                      0x030056fb -[NSObject(NSObject) doesNotRecognizeSelector:] + 187
    3   CoreFoundation                      0x02f75366 ___forwarding___ + 966
    4   CoreFoundation                      0x02f74f22 _CF_forwarding_prep_0 + 50
    5   WebKit                              0x03abc862 -[WebFrameView(WebInternal) _setWebFrame:] + 98
    6   WebKit                              0x03abc75f -[WebFrame(WebInternal) _initWithWebFrameView:webView:] + 239
    7   WebKit                              0x03af6565 +[WebFrame(WebInternal) _createMainFrameWithSimpleHTMLDocumentWithPage:frameView:withStyle:editable:] + 85
    8   WebKit                              0x03b30ad0 -[WebView(WebPrivate) initSimpleHTMLDocumentWithStyle:editable:withFrame:withPreferences:] + 1184
    9   UIKit                               0x019be211 -[UIWebDocumentView initSimpleHTMLDocumentWithStyle:editable:withFrame:withPreferences:] + 255
    10  UIKit                               0x019321e8 -[UITextView commonInitWithWebDocumentView:isDecoding:] + 443
    11  UIKit                               0x0192f5ce -[UITextView initWithFrame:] + 118

And it doesn't always crash there, sometimes it makes it through that call without issue, and then crashes here:

With the following excuse in the log:

Program received signal:  “EXC_BAD_ACCESS”.

Again, in this case the initial call (presenting a modal view controller) is made to a valid target with valid parameters, but this time the crash seems to be reporting a misaligned_stack_error_ as being the culprit.

Both of these issues started at around the same time, and only manifest in simulator, and only about 50% of the time (one, the other, or neither, it seems almost random).

Hoping someone else has seen this and might be able to point me in the right direction!

Answer 1

The issue was a really tough one, but looks like someone cracked the nut, we were using OS_vsnprintf (a wrapper for POSIX vsnprintf) for logging functionality, and were outputting logs to buffer without checking if the length of those log entries exceeded the buffer size (using \0 to terminate). This was causing buffer overflows which would poison other methods causing them to crash when called.

It was only present in debug because the really long log entries that were causing the buffer overflows were only present in debug. (tricky!)

So if you are having similar issues you might want to check your string handling and your C functionality to make sure you aren't accidentally causing buffer overflows!

Answer 2

Since it only occurs on simulator (i386) builds and the top line of the second stack trace is misaligned_stack_error_, you can try the following:

Add -mstackrealign to OTHER_CFLAGS in the main project.

Assuming this resolves the simulator issue and you encounter some problem building for device because of this flag you can do the following:

• Define two new custom build settings:

OTHER_CFLAGS_iphoneos = $(OTHER_CFLAGS)
OTHER_CFLAGS_iphonesimulator = -mstackrealign $(OTHER_CFLAGS)

• Set the Other C Flags build setting to:

$(OTHER_CFLAGS_$(PLATFORM_NAME))

Answer 3

Since you raised the possibility of a race condition in your subject, I assume your app is multi-threaded. Make sure you are only accessing UIKit objects from the main thread, as directed by the section on Multithreaded Cocoa Programs in the Cocoa Fundamentals Guide:

All UIKit objects should be used on the main thread only.

and the UIKit Framework Reference:

For the most part, UIKit classes should be used only from an application’s main thread. This is particularly true for classes derived from UIResponder or that involve manipulating your application’s user interface in any way.

Answer 4

Funny and strange ones!

Address alignement issues and unknown iOS SDK private methods...

Only on simulator, not device... with really basic standard code that works everywhere...

Unless you missed something that you didn't included in your question, like a really strange code, my two cents guess goes for a dirty development environment with dirty library links...

Tried cleaning / reinstalling Xcode?

---

EDIT : Since it doesn't look like:

• an environment issue (fails the same on any computer)
• a code issue : once again, the code you pasted is really basic, make sure you're not missing something! to be sure paste more code there.

I've came to another idea. I know, from experience, that LLVM2 is seriously bugged, especially concerning library linking.

If you're using LLVM2, could you try GCC4.2...?

Answer 5

I had a strange crashing problem recently also. Have you added any frameworks or compiler arguments to your project recently? If so, try clearing those out temporarily and see if that fixes your problem. In my case it was the UrbanAirship framework that was causing trouble.

Answer 6

Since it fails in one environment and "works" in the other, chances are you either have found a compiler bug (less likely) or it's memory related (more likely). In which case, the bug is still there on the device, you just haven't triggered it (yet).

Try running Instruments, searching for memory leaks, zombies. Examine all your dealloc calls, ensure you're zeroing properties, and calling [super dealloc]. A good tip is when you release an object, nil out the pointer to it too, so there's no dangling references.

If Instruments doesn't help, try to work out what exact steps are needed to reproduce the issue, so you know what areas to include in your search and which are irrelevant. Start commenting out code to rule it out. Eventually you'll narrow down your search enough and find the culprit.