Diagnosing Exc_Bad_Instruction in Swift Standard Library

EXC_BAD_INSTRUCTION Crash In Swift For locationManager(manager: CLLocationManager, didUpdateLocations locations: [CLLocation])

TLDR

There was a variable much farther down in my code that was nil. Unwrapping THAT variable caused the crash. The compiler was flagging the wrong line which leads to a whole host of confusion.

For full diagnosis look here:
https://stackoverflow.com/a/32659053/3324388

Swift: removing an object from NSOrderedSet

mutableCopy is a method, it must be called as a method, add () after it:

playset!.musicItems!.mutableCopy() as? NSMutableOrderedSet

You are currently trying to cast the method () -> Any? itself to an NSMutableOrderedSet, not the result of calling that method. Hence the warning.

The cast will never succeed and tempSet will always stay nil, crashing on the next !.

Xcode 13.2 SwiftUI Preview Crashes

Solved by adding ZStack in Preview struct solved it.. This is maybe a bug.
Solution

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
       ZStack {
           ContentView()
       }
    }
}

Xcode 6: How to Disable Optimisation (Swift)

In Xcode, look under 'Build Settings' for your target, scroll to 'Swift Compiler - Code Generation' and then 'Optimization Level'. Ensure that 'None' is selected.

Cryptic NSInternalInconsistencyException when running unit tests in Xcode 9 GM

I experienced a similar problem while working on some big suite of legacy code tests. The question is: are your tests with XCTExpectation working fine when you run them separately? If so, this means that some of the tests that are executed before your tests with NSInternalInconsistencyException are dispatching XCTest related methods in a way which executes them after the relevant test finishes.

it looks like (example):

Test1 -> dispatches asynchronously "block" which executes XCTFail

Test1 -> finishes

XCTFail executed (but Test1 passes, as it finished without "fail") on the main or other thread.

Test2 -> tests something with XCTExpectation -> NSInternalInconsistencyException

Apple docs don't provide much information about internal guts of XCTest, but I'm pretty sure that this is the issue. Try following troubleshooting steps to pin down tests "conflicting" (the bad ones which do asynchronous stuff without XCTestExpectation, like use methods with completion handlers which are eventually doing XCTest assertions, fails etc.):

1. Do binary search in your suite: disable half of the tests and run the suite with your FooTest.
2. If your test suite runs fine re-enable half of the disabled tests. If test suite runs with exception, re-enabled all disabled tests and disable other half.
3. Repeat step 1 then with respect to smaller amount of tests left.
4. Finally you will end up with tests which cause this exception.

In my case there were multiple tests causing this conflict with XCTestExpectation, hence the search was quite pesky (several hours for a suite of 1000+ XCTestCases, so around 5k tests).

Then investigate thoroughly what happens in the test which is conflicting with your test.

ARView Session Variable Not Allowed?

Ensure that you have import RealityKit. Also, ensure that you are targeting an actual device instead of an iOS simulator

Intercepting crashes on iOS

former Crashlytics iOS SDK maintainer here.

The code you've written above does have a number of technical issues.

The first is there are actually very few functions that are defined as safe to invoke inside a signal handler. man sigaction lists them. The code you've written is not signal-safe and will deadlock from time to time. It all will depend on what the crashed thread is doing at the time.

The second is you are attempting to just exit the program after your handler. You have to keep in mind that signals/exception handlers are process-wide resources, and you might not be the only one using them. You have to save pre-existing handlers and then restore them after handling. Otherwise, you can negatively affect other systems the app might be using. As you've currently written this, even Apple's own crash reporter will not be invoked. But, perhaps you want this behavior.

Third, you aren't capturing all threads stacks. This is critical information for a crash report, but adds a lot of complexity.

Fourth, signals actually aren't the lowest level error system. Not to be confused with run time exceptions (ie NSException) mach exceptions are the underlying mechanism used to implement signals on iOS. They are a much more robust system, but are also far more complex. Signals have a bunch of pitfalls and limitations that mach exceptions get around.

These are just the issues that come to me off the top of my head. Crash reporting is tricky business. But, I don't want you to think it's magic, of course it's not. You can build a system that works.

One thing I do want to point out, is that crash reporters give you no feedback on failure. So, you might build something that works 25% of the time, and because you are only seeing valid reports, you think "hey, this works great!". Crashlytics had to put in effort over many years to identify the causes of failure and try to mitigate them. If this is all interesting to you, you can check out a talk I did about the Crashlytics system.

Update:

So, what would happen if you ship this code? Well, sometimes you'll get useful reports. Sometimes, your crash handling code will itself crash, which will cause an infinite loop. Sometimes your code will deadlock, and effectively hang your app.

Apple has made exit public API (for better or worse), so you are absolutely within the rules to use it.

I would recommend continuing down this road for learning purposes only. If you have a real app that you care about, I think it would be more responsible to integrate an existing open-source reporting system and point it to a backend server that you control. No 3rd parties, but also no need to worry about doing more harm than good.

---

Related Topics