App Crash on Sign in (Xcode 9.3) Exc_Bad_Access (Code=1, Address=0X1)

App crash on sign in (xcode 9.3) EXC_BAD_ACCESS (code=1, address=0x1)

Have a similar issue with Facebook login - a work for me was found in the Xcode 9.3 release notes:

https://developer.apple.com/library/content/releasenotes/DeveloperTools/RN-Xcode/Chapters/Introduction.html#//apple_ref/doc/uid/TP40001051-CH1-DontLinkElementID_1

To quote them

In circumstances where protocol methods or base class methods defined
in Objective-C claim to take non-null arguments of type id in their
headers, but get invoked with nil values at runtime, Swift code
compiled by Xcode 9.3 that overrides those methods may crash when the
Swift implementations are invoked. (38675815) Workaround: Change the
Swift override to take a value of type Any?. For example, if you
implement the UIApplicationDelegate protocol's
application(_:open:sourceApplication:annotation:) method:

class AppDelegate: UIApplicationDelegate {
func application(_ application: UIApplication, open url: URL, sourceApplication: String?, annotation: Any) -> Bool {
    return true
}

The program may crash when passed nil as the annotation argument.
Avoid the crash by making the annotation argument have type Any?:

class AppDelegate: UIApplicationDelegate {
func application(_ application: UIApplication, open url: URL, sourceApplication: String?, annotation: Any?) -> Bool {
    return true
}

Xcode 9.3 build crashes on call with URL scheme (deeplink)

This is a bug on Swift4.1
https://bugs.swift.org/plugins/servlet/mobile#issue/SR-7240

Workaround is to replace function to following:

func application(_ app: UIApplication, open url: URL, options: [UIApplicationOpenURLOptionsKey : Any] = [:]) -> Bool {

EXC_BAD_ACCESS automatic handling

EXC_BAD_ACCESS doesn't generate an exception so you first function doesn't work with the case. It generates a signal SIGSEGV or SIGBUS.

Please refer to Handling unhandled exceptions and signals by Cocoa with Love.

Update

I just checked the source code of LLDB. It might be TARGET_EXC_BAD_ACCESS = 0x91.

In RNBRemote.h:

/* We translate the /usr/include/mach/exception_types.h exception types
   (e.g. EXC_BAD_ACCESS) to the fake BSD signal numbers that gdb uses
   in include/gdb/signals.h (e.g. TARGET_EXC_BAD_ACCESS).  These hard
   coded values for TARGET_EXC_BAD_ACCESS et al must match the gdb
   values in its include/gdb/signals.h.  */

#define TARGET_EXC_BAD_ACCESS      0x91
#define TARGET_EXC_BAD_INSTRUCTION 0x92
#define TARGET_EXC_ARITHMETIC      0x93
#define TARGET_EXC_EMULATION       0x94
#define TARGET_EXC_SOFTWARE        0x95
#define TARGET_EXC_BREAKPOINT      0x96

and in RNBRemote.cpp:

// Translate any mach exceptions to gdb versions, unless they are
// common exceptions like a breakpoint or a soft signal.
switch (tid_stop_info.details.exception.type)
{
    default:                    signum = 0; break;
    case EXC_BREAKPOINT:        signum = SIGTRAP; break;
    case EXC_BAD_ACCESS:        signum = TARGET_EXC_BAD_ACCESS; break;
    case EXC_BAD_INSTRUCTION:   signum = TARGET_EXC_BAD_INSTRUCTION; break;
    case EXC_ARITHMETIC:        signum = TARGET_EXC_ARITHMETIC; break;
    case EXC_EMULATION:         signum = TARGET_EXC_EMULATION; break;
    case EXC_SOFTWARE:
        if (tid_stop_info.details.exception.data_count == 2 &&
            tid_stop_info.details.exception.data[0] == EXC_SOFT_SIGNAL)
            signum = tid_stop_info.details.exception.data[1];
        else
            signum = TARGET_EXC_SOFTWARE;
        break;
}

How to write a BOOL predicate in Core Data?

From Predicate Programming Guide:

You specify and test for equality of Boolean values as illustrated in the following examples:

NSPredicate *newPredicate = [NSPredicate predicateWithFormat:@"anAttribute == %@", [NSNumber numberWithBool:aBool]];
NSPredicate *testForTrue = [NSPredicate predicateWithFormat:@"anAttribute == YES"];

You can also check out the Predicate Format String Syntax.

Stack overflow: Thread 1: EXC_BAD_ACCESS (code=2, address=0x16d09aa00)

TL;DR

Just move huge structs to the heap, by wrapping them inside arrays. Using @propertyWrappers, this can be an at least partly elegant solution.

@propertyWrapper
struct StoredOnHeap<T> {
    private var value: [T]

    init(wrappedValue: T) {
        self.value = [wrappedValue]
    }

    var wrappedValue: T {
        get {
            return self.value[0]
        }

        set {
            self.value[0] = newValue
        }
    }
}

// Usage:
@StoredOnHeap var hugeStruct: HugeStruct

https://gist.github.com/d4rkd3v1l/ab582a7cafd3a8b8c164c8541a3eef96

---

Long version

I'm almost 100% certain now, that this is a stack overflow, as I (finally) managed to reproduce this in a little demo project: https://github.com/d4rkd3v1l/ReSwift-StackOverflowDemo

Now I will just provide some more details and solutions for anyone else may running into this or similar issues.

The stack size on iOS (as of iOS 13) is 512kb and should apply to both, devices and simulators. Why did I say "should"? Because it almost certainly is somewhat different on simulators, as I did not see those crashes there. So maybe Thread.main.stackSize just tells 512kb but is in fact larger? IDK ‍♂️

---

Here are some indicators, you may face the same issue:

• You get EXC_BAD_ACCESS crashes with code 1 or 2**. And the crashes occur in high memory addresses, or at least completely out of where the rest of your app/stack normally "lives". Something like 0x16d95ad00 in my case.
• Reducing the stuff you put on the stack (value types, e.g. very very large structs) or breaking the call stack down into smaller pieces (e.g. dispatch async) to give the stack some "time to breathe" prevents this crash.

And here at the latter we're already in the middle of the solution for that issue. As the stack size cannot (and probably even should not) increased, you must reduce the load you put there, like described in the 2nd point.

At least that's the solution we will probably go for. /p>

---

*This is true at least for the main thread, other threads may be different.

**I think code 0 is kinda null pointer exceptionand therefore doesn't apply here. Please correct me if I'm wrong about this.

React Native App Crash (Thread 1: EXC_BAD_ACCESS (code=1, address=0x54))

After tons of debugging, confusion, and many hours of frustration it came down to removing and readding one dependency. There was no specific error message I could trace or change I could find in our git history that would've caused this. I literally ended up tediously removing code from the App until I found the library that was the problem.

Thread 1: EXC_BAD_ACCESS (code=1, address=0x40)

When your app crashed, Xcode should've shown the line which caused the crash. That should give you some clues.

Essentially a EXC_BAD_ACCESS is when your trying to access an object that's already been deallocated. So this means your problem might also be earlier in the code and not exactly at the line where it crashed.

This website shows a couple of ways that might help you figure out what's the problem.

Hope this helps!

getting strange Thread 1: EXC_BAD_ACCESS (code=1, address=0x9) crash error in swift

I don't know why this happens and I don't know why below solution works for it. if anyone has more information I will be glad to know.

Solution
checking Allow testing Host Application APIs for test target in Xcode, fixed the error.

---

Related Topics