堆栈溢出：线程 1：EXC_BAD_ACCESS（代码=2，地址=0x16d09aa00）

Question

崩溃描述

最近，我在我的一个 iOS/Swift 项目中遇到了非常奇怪的内存问题。我真的不确定发生了什么，感觉也不太容易描述，但无论如何我会尽力而为。

它的基本行为如下：

• 在某个代码库上，崩溃总是发生在同一个地方（100% 可重现）
• 更改代码库，可能会解决问题，但也可能只是在其他地方弹出
• 崩溃只发生在真实设备上，永远不会发生在模拟器内

目前该应用程序崩溃并出现以下错误（3 次不同运行的结果）：

线程 1：EXC_BAD_ACCESS（代码=2，地址=0x16d09aa00）

线程 1：EXC_BAD_ACCESS（代码=2，地址=0x16af46a00）

线程 1：EXC_BAD_ACCESS（代码=2，地址=0x16d526a00）

---

关于内存地址的推理

世界开发者大会

我在WWDC 2018 上发现了一个有趣的会议（Understanding Crashes and Crash Logs），其中一个人指出有时可以从特定的内存地址中获取更多信息，崩溃就会发生。

不幸的是，它在我的应用程序中崩溃的地址有些完全不同，但也许我们可以从它们那里获得线索？至少有趣的是，它们都非常相似，不是吗？

由于启用了诊断选项而发生的变化

进一步调查表明，前 2 个字节 (16) 始终保持不变，然后是 4 个随机字节，然后是 3 个字节 (a00)。当激活诊断（例如 ASan 或 Scribble）时，最后 3 个字节会改变（例如 3a0 或 9e0）。但也许这只是由于添加了更多“调试内容”而导致的一种转变？我真的不是那个“记忆人”，只是想提供我注意到的任何东西。

---

尝试“诊断选项”

我尝试了不同的诊断选项（来自方案），但没有一个真正以任何方式改变崩溃，或提供更多信息。

1. 涂鸦

崩溃不引用 0xAA 或 0x55，所以使用 Scribble 没有什么可以捕获的吗？（Xcode - 涂鸦，保护边缘和保护 malloc）

2. Malloc Guard Edges

使用这个也没有注意到任何区别。

3. 僵尸

使用本指南。

malloc_info --type 0x16b15e9c0

错误：错误：试图将堆栈放入无法读取的内存中：0x16b15e920。

4.阿桑

使用 ASan 只是将以下条目放在堆栈跟踪的顶部。不幸的是，我没有发现任何与此相关的有用信息。

#0 0x0000000109efbf60 in __asan_alloca_poison ()

5. 散

在真实设备上不可用（崩溃只发生在那里）

---

递归/BOF？

可能是递归太长，还是另一种堆栈/堆缓冲区溢出？但看起来真实设备和模拟器上的堆栈大小与524288字节（来自Thread.main.stackSize）完全相同。

那么，因为它不会在模拟器中崩溃，所以它不是 BOF？还是架构差异太大，无法在此下结论？

---

拆卸

我也尝试过“拆卸”。

disassemble -a 0x16d09aa00

错误：找不到地址 0x16d09aa00 的函数边界

或者 disassemble -frame

但是我的汇编技能真的很落后，所以目前我无法从这些信息中得到任何信息。

---

需要帮忙

正如你所看到的，我真的没有想法了。要么崩溃真的很奇怪，要么我没有足够的知识/技能来使用上述工具，让我更接近这些问题的原因。

无论哪种方式......任何帮助，提示，想法或任何可以为我指明正确方向的东西都非常感谢！

提前致谢，伙计们。

---

2020 年 5 月 19 日更新

我完全忘了提及，我们在我们的应用程序中大量使用ReSwift，我猜这些崩溃似乎与我们在那里使用中间件的方式有关。

我也已经与那里的开发人员联系了：github.com/ReSwift/ReSwift/issues/271。

最后是一些代码。不幸的是，我不能分享所有的应用程序代码（这可能是必要的！？），也不想用太多的代码让你过载。

当前的问题

线程 1：EXC_BAD_ACCESS（代码=1，地址=0x16ed82da0）

UserAccountMiddleware.swift

注意：使用这些DispatchQueue.main.async实际上会使崩溃消失。他们确实打破了当前的循环，所以也许发生了某种递归或时间问题？

func userAccountMiddleware() -> Middleware<AppState> {
    return { dispatch, getState in
        return { next in
            return { action in
                switch action {
                case _ as ReSwiftInit:
//                    DispatchQueue.main.async {
                        dispatch(UserAccountSetAuthToken(authToken: Defaults.customerAuthToken))
                        dispatch(UserAccountSetAvatar(index: Defaults.avatarIndex))
//                    }
                    if let data = Defaults.customer,
                        let customer = try? JSONDecoder().decode(Customer.self, from: data) {
//                        DispatchQueue.main.async {
                            dispatch(UserAccountSetCustomerLoggedIn(customer: customer))
//                        }
                    }

                // [...]

                default:
                    break
                }

                next(action)
            }
        }
    }
}

ReSwift Store.swift

    // [...]
    open func _defaultDispatch(action: Action) {
        guard !isDispatching else {
            raiseFatalError(
                "ReSwift:ConcurrentMutationError- Action has been dispatched while" +
                " a previous action is action is being processed. A reducer" +
                " is dispatching an action, or ReSwift is used in a concurrent context" +
                " (e.g. from multiple threads)."
            )
        }

        isDispatching = true
        let newState = reducer(action, state) // Thread 1: EXC_BAD_ACCESS (code=1, address=0x16ed82da0)
        isDispatching = false

        state = newState
    }
    // [...]

Xcode控制台：

(lldb) po state
error: warning: couldn't get required object pointer (substituting NULL): Couldn't load 'self' because its value couldn't be evaluated

error: Trying to put the stack in unreadable memory at: 0x16d95ad00.

汇编程序（崩溃的最后一步）：

myapp`type metadata accessor for GlobalState:
    0x101f6ac10 <+0>:  sub    sp, sp, #0x30             ; =0x30 
->  0x101f6ac14 <+4>:  stp    x29, x30, [sp, #0x20] // Thread 1: EXC_BAD_ACCESS (code=1, address=0x16ed82da0)
    0x101f6ac18 <+8>:  adrp   x8, 3620
    0x101f6ac1c <+12>: add    x8, x8, #0x148            ; =0x148 
    0x101f6ac20 <+16>: ldr    x8, [x8]
    0x101f6ac24 <+20>: mov    x9, #0x0
    0x101f6ac28 <+24>: mov    x1, x8
    0x101f6ac2c <+28>: str    x0, [sp, #0x18]
    0x101f6ac30 <+32>: str    x1, [sp, #0x10]
    0x101f6ac34 <+36>: str    x9, [sp, #0x8]
    0x101f6ac38 <+40>: cbnz   x8, 0x101f6ac54           ; <+68> at <compiler-generated>
    0x101f6ac3c <+44>: adrp   x1, 2122
    0x101f6ac40 <+48>: add    x1, x1, #0x1dc            ; =0x1dc 
    0x101f6ac44 <+52>: ldr    x0, [sp, #0x18]
    0x101f6ac48 <+56>: bl     0x102775358               ; symbol stub for: swift_getSingletonMetadata
    0x101f6ac4c <+60>: str    x0, [sp, #0x10]
    0x101f6ac50 <+64>: str    x1, [sp, #0x8]
    0x101f6ac54 <+68>: ldr    x0, [sp, #0x8]
    0x101f6ac58 <+72>: ldr    x1, [sp, #0x10]
    0x101f6ac5c <+76>: str    x0, [sp]
    0x101f6ac60 <+80>: mov    x0, x1
    0x101f6ac64 <+84>: ldr    x1, [sp]
    0x101f6ac68 <+88>: ldp    x29, x30, [sp, #0x20]
    0x101f6ac6c <+92>: add    sp, sp, #0x30             ; =0x30 
    0x101f6ac70 <+96>: ret     

Answer 1

TL; 博士

只需将巨大的结构移动到堆中，将它们包装在数组中。使用@propertyWrappers，这至少是一个优雅的解决方案。

@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

长版

我现在几乎 100% 肯定，这是一个堆栈溢出，因为我（最终）设法在一个小演示项目中重现了这个：https : //github.com/d4rkd3v1l/ReSwift-StackOverflowDemo

现在，我将为其他可能遇到此问题或类似问题的人提供更多详细信息和解决方案。

iOS 上的堆栈大小（从 iOS 13 开始）为 512kb，应该适用于设备和模拟器。我为什么说“应该”？因为它几乎可以肯定在模拟器上有些不同，因为我没有在那里看到那些崩溃。所以也许Thread.main.stackSize只是告诉 512kb 但实际上更大？身份证？？？

以下是一些指标，您可能面临同样的问题：

• EXC_BAD_ACCESS代码 1 或 2**会导致崩溃。并且崩溃发生在高内存地址中，或者至少完全不在应用程序/堆栈的其余部分通常“存在”的地方。就像0x16d95ad00我的情况一样。
• 减少你放在堆栈上的东西（值类型，例如非常非常大的结构）或将调用堆栈分解成更小的部分（例如调度异步）以给堆栈一些“喘息的时间”，以防止这种崩溃。

在后者方面，我们已经在解决该问题的过程中了。由于堆栈大小不能（甚至可能不应该）增加，您必须减少放置在那里的负载，如第二点所述。

至少这是我们可能会寻求的解决方案。

*至少对于主线程是这样，其他线程可能不同。

**我认为代码 0 是一种空指针异常，因此不适用于此处。如果我错了，请纠正我。