在本章中，我們將學習錯誤的內存崩潰。

在崩潰報告中，我們可以通過異常類型?EXC_BAD_ACCESS (SIGSEGV)?或?EXC_BAD_ACCESS (SIGBUS)來進行區分。

我們來看看通過搜索互聯網獲得的一系列崩潰現象。

一般原則

在操作系統中，管理內存的方法是首先將連續的內存排序為內存頁，然后將頁面排序為段。這允許將元數據屬性分配給應用于該段內的所有頁面的段。這允許我們的程序代碼(程序?TEXT?)被設置為只讀但可執行。提高了性能和安全性。

SIGBUS(總線錯誤)表示內存地址已正確映射到進程的地址區間，但不允許進程訪問內存。

SIGSEGV(段沖突)表示存儲器地址甚至沒有映射到進程地址區間。

段沖突 (SEGV)崩潰

fud 崩潰

fud?程序是私有框架?MobileAccessoryUpdater中的一個未記錄的進程。

在這里，我們顯示了macOS上進程?fud的崩潰報告，為了便于演示，該報告已被截斷：

Process: fud [84641]
Path: /System/Library/PrivateFrameworks/
MobileAccessoryUpdater.framework/Support/fud
Identifier: fud
Version: 106.50.4
Code Type: X86-64 (Native)
Parent Process: launchd [1]
Responsible: fud [84641]
User ID: 0

Date/Time: 2018-06-12 08:34:15.054 +0100
OS Version: Mac OS X 10.13.4 (17E199)
Report Version: 12
Anonymous UUID: 6C1D2091-02B7-47C4-5BF9-E99AD5C45875

Sleep/Wake UUID: 369D13CB-F0D3-414B-A177-38B1E560EEC7

Time Awake Since Boot: 240000 seconds
Time Since Wake: 47 seconds

System Integrity Protection: enabled

Crashed Thread: 1
Dispatch queue: com.apple.fud.processing.queue

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: EXC_I386_GPFLT
Exception Note: EXC_CORPSE_NOTIFY

Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [0]

Thread 1 Crashed:: Dispatch queue:
com.apple.fud.processing.queue
0 libdispatch.dylib 0x00007fff67fc6cbd
_dispatch_continuation_push + 4
1 fud 0x0000000101d3ce57
__38-[FudController handleXPCStreamEvent:]_block_invoke + 593
2 libdispatch.dylib 0x00007fff67fbb64a
_dispatch_call_block_and_release + 12
3 libdispatch.dylib 0x00007fff67fb3e08
_dispatch_client_callout + 8
4 libdispatch.dylib 0x00007fff67fc8377
_dispatch_queue_serial_drain + 907
5 libdispatch.dylib 0x00007fff67fbb1b6
_dispatch_queue_invoke + 373
6 libdispatch.dylib 0x00007fff67fc8f5d
_dispatch_root_queue_drain_deferred_wlh + 332
7 libdispatch.dylib 0x00007fff67fccd71
_dispatch_workloop_worker_thread + 880
8 libsystem_pthread.dylib 0x00007fff68304fd2
_pthread_wqthread + 980
9 libsystem_pthread.dylib 0x00007fff68304be9
start_wqthread + 13

Thread 1 crashed with X86 Thread State (64-bit):
rax: 0xe00007f80bd22039 rbx: 0x00007f80bd2202e0
rcx: 0x7fffffffffffffff
rdx: 0x011d800101d66da1
rdi: 0x00007f80bd21a250 rsi: 0x0000000102c01000
rbp: 0x0000700007e096c0
rsp: 0x0000700007e09670
r8: 0x0000000102c00010 r9: 0x0000000000000001
r10: 0x0000000102c01000
r11: 0x00000f80b5300430
r12: 0x00007f80ba70c670 r13: 0x00007fff673c8e80
r14: 0x00007f80bd201e00
r15: 0x00007f80ba70cf30
rip: 0x00007fff67fc6cbd rfl: 0x0000000000010202
cr2: 0x00007fff9b2f11b8

Logical CPU: 3
Error Code: 0x00000004
Trap Number: 14

我們顯然有一個不好的內存問題，因為我們有一個EXC_BAD_ACCESS (SIGSEGV)(SIGSEGV)異常。我們看到的錯誤代碼是 14，在https://github.com/apple/darwin-xnu中屬于缺頁中斷。

由于?libdispatch是 Apple 開源的，我們甚至可以查找觸發崩潰的函數。(“Libdispatch Open Source” 2018)

我們看到：

#define dx_push(x, y, z) dx_vtable(x)->do_push(x, y, z)

DISPATCH_NOINLINE
static void
_dispatch_continuation_push(dispatch_queue_t dq,
dispatch_continuation_t dc)
{
dx_push(dq, dc, _dispatch_continuation_override_qos(dq, dc));
}

我們正在從一個有錯誤內存位置的數據結構中解除內存引用。

我們可以反匯編問題調用站點的macOS二進制文件/usr/lib/system/libdispatch.dylib。

在這里，我們使用 Hopper 進行脫殼：

__dispatch_continuation_push:
0000000000014c69 push rbx
; CODE XREF=__dispatch_async_f2+112,
j___dispatch_continuation_push
0000000000014c6a mov rax, qword [rdi]
0000000000014c6d mov r8, qword [rax+0x40]
0000000000014c71 mov rax, qword [rsi+8]
0000000000014c75 mov edx, eax
0000000000014c77 shr edx, 0x8
0000000000014c7a and edx, 0x3fff
0000000000014c80 mov ebx, dword [rdi+0x58]
0000000000014c83 movzx ecx, bh
0000000000014c86 je loc_14ca3

rdi寄存器值似乎有問題，地址為?0x00007f80bd21a250

我們需要退一步，了解為什么我們有內存訪問問題。

查看堆?；厮?#xff0c;我們可以看到該程序使用跨進程通信(XPC)來完成其工作。它有?handleXPCStreamEvent?函數。

這是一個常見的編程問題，當我們接收到一個數據有效負載時，就會出現解壓縮有效負載和解釋數據的問題。我們推測反序列化代碼中有一個bug。這將給我們一個潛在的壞數據結構，我們取消引用會導致崩潰。

如果我們是fud程序的作者，我們可以對其進行更新以檢查它獲得的XPC數據，并確保遵循最佳實踐進行數據的序列化/反序列化，例如使用接口定義層生成器。

LeakAgent 崩潰

蘋果提供了?LeakAgent?程序作為其內存診斷工具的一部分。它在 Xcode Instruments 中使用。

以下是崩潰報告，?LeakAgent?發生了崩潰，為了便于演示而被截斷：

Incident Identifier: 11ED1987-1BC9-4F44-900C-AD07EE6F7E26
CrashReporter Key: b544a32d592996e0efdd7f5eaafd1f4164a2e13c
Hardware Model: iPad6,3
Process: LeakAgent [3434]
Path: /Developer/Library/PrivateFrameworks/
DVTInstrumentsFoundation.framework/LeakAgent
Identifier: LeakAgent
Version: ???
Code Type: ARM-64 (Native)
Role: Unspecified
Parent Process: DTServiceHub [1592]
Coalition: com.apple.instruments.deviceservice
[463]


Date/Time: 2018-07-19 14:16:57.6977 +0100
Launch Time: 2018-07-19 14:16:56.7734 +0100
OS Version: iPhone OS 11.3 (15E216)
Baseband Version: n/a
Report Version: 104

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at
0x0000000000000000
VM Region Info: 0 is not in any region.
Bytes before following region: 4371873792
REGION TYPE START - END
[ VSIZE] PRT/MAX SHRMOD REGION DETAIL
UNUSED SPACE AT START
--->
__TEXT 0000000104958000-0000000104964000
[ 48K] r-x/r-x SM=COW ...ork/LeakAgent

Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [0]
Triggered by Thread: 4

Thread 4 name: Dispatch queue:
DTXChannel serializer queue [x1.c0]
Thread 4 Crashed:
0 libswiftDemangle.dylib
0x0000000104f871dc 0x104f70000 + 94684
1 libswiftDemangle.dylib
0x0000000104f8717c 0x104f70000 + 94588
2 libswiftDemangle.dylib
0x0000000104f86200 0x104f70000 + 90624
3 libswiftDemangle.dylib
0x0000000104f84948 0x104f70000 + 84296
4 libswiftDemangle.dylib
0x0000000104f833a4 0x104f70000 + 78756
5 libswiftDemangle.dylib
0x0000000104f73290 0x104f70000 + 12944
6 CoreSymbolication
0x000000019241d638 demangle + 112
7 CoreSymbolication
0x00000001923d16cc
TRawSymbol::name+ 54988 () + 72
8 CoreSymbolication
0x0000000192404ff4
TRawSymbolOwnerData::
symbols_for_name(CSCppSymbolOwner*, char const*,
void + 266228 (_CSTypeRef) block_pointer) + 156
9 CoreSymbolication
0x00000001923d9734
CSSymbolOwnerGetSymbolWithName + 116
10 Symbolication
0x000000019bb2e7f4
-[VMUObjectIdentifier _targetProcessSwiftReflectionVersion]
+ 120
11 Symbolication
0x000000019bb2f9d8
-[VMUObjectIdentifier loadSwiftReflectionLibrary] + 36
12 Symbolication
0x000000019bb29ff0
-[VMUObjectIdentifier initWithTask:symbolicator:scanner:]
+ 436
13 Symbolication
0x000000019baede10
-[VMUTaskMemoryScanner _initWithTask:options:] + 2292
14 Symbolication
0x000000019baee304
-[VMUTaskMemoryScanner initWithTask:options:] + 72
15 LeakAgent
0x000000010495b270 0x104958000 + 12912
16 CoreFoundation
0x0000000183f82580 __invoking___ + 144
17 CoreFoundation 0x0000000183e61748
-[NSInvocation invoke] + 284
18 DTXConnectionServices
0x000000010499f230 0x104980000 + 127536
19 DTXConnectionServices
0x00000001049947a4 0x104980000 + 83876
20 libdispatch.dylib 0x000000018386cb24
_dispatch_call_block_and_release + 24
21 libdispatch.dylib 0x000000018386cae4
_dispatch_client_callout + 16
22 libdispatch.dylib 0x0000000183876a38
_dispatch_queue_serial_drain$VARIANT$mp + 608
23 libdispatch.dylib 0x0000000183877380
_dispatch_queue_invoke$VARIANT$mp + 336
24 libdispatch.dylib 0x0000000183877d4c
_dispatch_root_queue_drain_deferred_wlh$VARIANT$mp + 340
25 libdispatch.dylib 0x000000018388011c
_dispatch_workloop_worker_thread$VARIANT$mp + 668
26 libsystem_pthread.dylib 0x0000000183b9fe70
_pthread_wqthread + 860
27 libsystem_pthread.dylib
0x0000000183b9fb08 start_wqthread + 4
Thread 4 crashed with ARM Thread State (64-bit):
x0: 0x0000000000000000 x1: 0x0000000000000000
x2: 0xfffffffffffffff6
x3: 0x0000000000000041
x4: 0x0000000000000000 x5: 0x0000000104f97950
x6: 0x0000000000000006
x7: 0x00000000ffffffff
x8: 0x00000001050589d0 x9: 0x0000000104f840d8
x10: 0xffffffffffffd544
x11: 0x0000000000000a74
x12: 0x0000000000000002 x13: 0x00000000000002aa
x14: 0x00000000000002aa
x15: 0x00000000000003ff
x16: 0x0000000183b96360 x17: 0x0000000000200000
x18: 0x0000000000000000
x19: 0x000000016b6d1ba0
x20: 0x00000001050589a0 x21: 0x0000000000000000
x22: 0x0000000000000000
x23: 0x0000000000000001
x24: 0x00000000ffffffff x25: 0x0000000000000006
x26: 0x0000000104f97950
x27: 0x0000000000000000
x28: 0x0000000000000009 fp: 0x000000016b6d19c0
lr: 0x0000000104f8717c
sp: 0x000000016b6d1930 pc: 0x0000000104f871dc
cpsr: 0x60000000

我們可以看到出錯的內核地址是0x0000000000000000，所以它是一個空指針解引用。我們崩潰的調用站點是一個分解符號的 Swift 庫。Xcode 工具試圖從它在 iPad 上看到的活動中提供人類可讀的對象類型定義。

如果我們是用戶并視圖分析我們的應用程序，然后在LeakAgent中遇到此錯誤，那么我們需要嘗試找出避免該問題的方法。

由于問題是由于符號化造成的，所以明智的做法是清除構建目錄，然后進行一次干凈的構建。有時，Xcode更新會將我們切換到不兼容的新目標文件格式。值得與另一個項目(可能是微不足道的測試程序)一起檢查性能。還有其他內存分析工具，例如我們正在運行的方案的診斷選項，因此可以用不同的方式進行內存分析。有關更多信息，請參見下一章內存診斷 。

總線錯誤(SIGBUS)崩潰

xbmc 崩潰

xbmc?應用程序是一款實用應用程序，其作用類似于電視媒體播放器的遙控器。

在啟動過程中，應用程序發生崩潰并產生以下崩潰報告，為便于演示，該報告已被截斷：

Incident Identifier: 396B3641-5F74-4B01-9E62-FE24A2C12E92
CrashReporter Key: 14aa0286b8b087d8b6a1ca75201a3f7d8c52d5bd
Hardware Model: iPad1,1
Process: XBMC [5693]
Path: /var/mobile/Applications/
94088F35-1CDB-47CD-9D3C-328E39C2589F/XBMC.app/XBMC
Identifier: XBMC
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]

Date/Time: 2011-04-10 11:52:44.575 +0200
OS Version: iPhone OS 4.3.1 (8G4)
Report Version: 104

Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: 0x00000032, 0x047001b0
Crashed Thread: 4

Thread 4 Crashed:
0 dyld 0x2fe1c8a0 strcmp + 0
1 dyld 0x2fe0ce32
ImageLoaderMachO::parseLoadCmds() + 30
2 dyld 0x2fe1262c
ImageLoaderMachOCompressed::instantiateFromFile
(char const*, int,
unsigned char const*, unsigned long long,
unsigned long long,
stat const&, unsigned int, unsigned int,
linkedit_data_command const*,
ImageLoader::LinkContext const&) + 228
3 dyld 0x2fe0da14
ImageLoaderMachO::instantiateFromFile
(char const*, int,
unsigned char const*, unsigned long long,
unsigned long long,
stat const&, ImageLoader::LinkContext const&) + 348
4 dyld 0x2fe052e8
dyld::loadPhase6(int, stat const&, char const*,
dyld::LoadContext const&) + 576
5 dyld 0x2fe053fe
dyld::loadPhase5stat(char const*,
dyld::LoadContext const&, stat*,
int*, bool*, std::vector std::allocator >*) + 174
6 dyld 0x2fe055b4
dyld::loadPhase5(char const*, char const*,
dyld::LoadContext const&,
std::vector std::allocator >*) + 232
7 dyld 0x2fe057fe
dyld::loadPhase4(char const*, char const*,
dyld::LoadContext const&,
std::vector std::allocator >*) + 302
8 dyld 0x2fe064b2
dyld::loadPhase3(char const*, char const*,
dyld::LoadContext const&,
std::vector std::allocator >*) + 2514
9 dyld 0x2fe065d0
dyld::loadPhase1(char const*, char const*,
dyld::LoadContext const&,
std::vector std::allocator >*) + 88
10 dyld 0x2fe06798
dyld::loadPhase0(char const*, char const*,
dyld::LoadContext const&,
std::vector std::allocator >*) + 368
11 dyld 0x2fe0688e
dyld::load(char const*, dyld::LoadContext const&) + 178
12 dyld 0x2fe08916 dlopen + 574
13 libdyld.dylib 0x3678b4ae dlopen + 30
14 XBMC 0x002276d4
SoLoader::Load() (SoLoader.cpp:57)
15 XBMC 0x0002976c
DllLoaderContainer::LoadDll(char const*, bool)
(DllLoaderContainer.cpp:250)
16 XBMC 0x000299ce
DllLoaderContainer::FindModule(char const*, char const*,
bool) (DllLoaderContainer.cpp:147)
17 XBMC 0x00029cca
DllLoaderContainer::LoadModule(char const*, char const*,
bool) (DllLoaderContainer.cpp:115)
18 XBMC 0x0010c1a4
CSectionLoader::LoadDLL(CStdStr const&, bool,
bool) (SectionLoader.cpp:138)
19 XBMC 0x000e9b10
DllDynamic::Load() (DynamicDll.cpp:52)
20 XBMC 0x002096c6
ADDON::CAddonMgr::Init() (AddonManager.cpp:215)
21 XBMC 0x004e447a
CApplication::Create() (Application.cpp:644)
22 XBMC 0x00510e42
-[XBMCEAGLView runAnimation:] (XBMCEAGLView.mm:312)
23 Foundation 0x3505b382
-[NSThread main] + 38
24 Foundation
0x350cd5c6 __NSThread__main__ + 966
25 libsystem_c.dylib
0x3035530a _pthread_start + 242
26 libsystem_c.dylib
0x30356bb4 thread_start + 0
Thread 4 crashed with ARM Thread State:
r0: 0x047001b0 r1: 0x2fe20ef0 r2: 0x01fe5f04
r3: 0x2fe116d1
r4: 0x00000001 r5: 0x01a46740 r6: 0x00000000
r7: 0x01fe5264
r8: 0x01a3f0fc r9: 0x00000012 r10: 0x01fe6e60
r11: 0x00000007
ip: 0x2fe262f8 sp: 0x01fe5234 lr: 0x2fe0ce39
pc: 0x2fe1c8a0
cpsr: 0x00000010
Binary Images:
0x1000 - 0xd98fff +XBMC armv7
/var/mobile/Applications/
94088F35-1CDB-47CD-9D3C-328E39C2589F/
XBMC.app/XBMC
0x2fe00000 - 0x2fe25fff dyld armv7
<8dbdf7bab30e355b81e7b2e333d5459b>
/usr/lib/dyld

在此崩潰案例中，我們通過崩潰報告異常代碼部分的第二個值說明了在位置0x047001b0?處的錯誤內存：

Exception Codes: 0x00000032, 0x047001b0

注意，這也顯示為寄存器?r0?的值(通常是這種情況)

這個值高于 XBMC 應用程序的二進制映射范圍，低于崩潰報告的二進制映射部分中的?dyld?范圍。

該地址必須映射到其中，但我們不知道崩潰報告將其映射到哪個段。

我們可以看到該應用程序可以動態配置。從回溯中我們可以看到：

13 libdyld.dylib 0x3678b4ae dlopen + 30
14 XBMC 0x002276d4
SoLoader::Load() (SoLoader.cpp:57)

它正在調用動態加載程序，并根據 “AddOn” 管理器確定配置加載額外的代碼：

20 XBMC 0x002096c6
ADDON::CAddonMgr::Init() (AddonManager.cpp:215)

診斷此類問題的最簡單方法是讓應用程序在嘗試在運行時加載可選軟件框架之前記錄其配置。應用程序包可能缺少我們想要的庫。

有時我們會集成第三方庫，這些庫中具有動態代碼加載功能。在這種情況下，我們需要使用 Xcode 診斷工具。

我們沒有XBMC應用程序的源代碼。但是，有一個開源示例演示了動態加載程序的使用。?(“Dynamic Loading Example” 2018)

當我們運行該程序時，我們可以在應用程序編碼的動態加載程序的使用中看到有用的消息。此外，我們可以通過如下修改 Scheme 設置, Dynamic Linker API Usage?:

啟動該程序后，我們可以看到它如何動態加載模塊。除了我們的應用程序消息外，我們還會收到系統生成的消息。系統消息沒有時間戳前綴，但應用程序消息卻有。

這是一個經過修剪的調試日志，顯示了我們看到的輸出類型:

2018-08-18 12:26:51.989237+0100
ios-dynamic-loading-framework[2962:109722]
App started
2018-08-18 12:26:51.992187+0100
ios-dynamic-loading-framework[2962:109722]
Before referencing CASHello in DynamicFramework1
dlopen(DynamicFramework1.framework/DynamicFramework1, 0x00000001)
2018-08-18 12:26:52.002234+0100
ios-dynamic-loading-framework[2962:109722]
Loading CASHello in dynamic-framework-1
dlopen(DynamicFramework1.framework/DynamicFramework1) ==>
0x600000157ce0
2018-08-18 12:26:52.002398+0100
ios-dynamic-loading-framework[2962:109722]
Loaded CASHello in DynamicFramework1
dlclose(0x600000157ce0)
2018-08-18 12:26:52.002560+0100
ios-dynamic-loading-framework[2962:109722]
CASHello from DynamicFramework1 still loaded after dlclose()
2018-08-18 12:26:52.002642+0100
ios-dynamic-loading-framework[2962:109722]
Before referencing CASHello in DynamicFramework2
dlopen(DynamicFramework2.framework/DynamicFramework2, 0x00000001)
objc[2962]: Class CASHello is implemented in both
/Users/faisalm/Library/
Developer/Xcode/DerivedData/
ios-dynamic-loading-framework-ednexaanxalgpudjcqeuejsdmhlq/Build
/Products/Debug-iphonesimulator/
DynamicFramework1.framework/DynamicFramework1 (0x1229cb178)
and
/Users/faisalm/Library/Developer/Xcode/DerivedData/
ios-dynamic-loading-framework-ednexaanxalgpudjcqeuejsdmhlq/Build
/Products/Debug-iphonesimulator/DynamicFramework2.framework/
DynamicFramework2
(0x1229d3178).
One of the two will be used. Which one is undefined.
2018-08-18 12:26:52.012601+0100
ios-dynamic-loading-framework[2962:109722]
Loading CASHello in dynamic-framework-2
dlopen(DynamicFramework2.framework/DynamicFramework2) ==>
0x600000157d90
2018-08-18 12:26:52.012792+0100
ios-dynamic-loading-framework[2962:109722]
Loaded CASHello in DynamicFramework2
dlclose(0x600000157d90)
2018-08-18 12:26:52.012921+0100
ios-dynamic-loading-framework[2962:109722]
CASHello from DynamicFramework2 still loaded after dlclose()

這是加載?DynamicFramework1的相關源代碼。

-(void)loadCASHelloFromDynamicFramework1
{
void *framework1Handle = dlopen(
"DynamicFramework1.framework/DynamicFramework1", RTLD_LAZY);

if (NSClassFromString(@"CASHello"))
{
NSLog(@"Loaded CASHello in DynamicFramework1");
}
else
{
NSLog(@"Could not load CASHello in DynamicFramework1");
}

dlclose(framework1Handle);

if (NSClassFromString(@"CASHello"))
{
NSLog(
@"CASHello from DynamicFramework1 still loaded after dlclose()"
);
}
else
{
NSLog(@"Unloaded DynamicFramework1");
}
}

這是在的?viewDidLoad?中調用它的代碼：

- (void)viewDidLoad
{
[super viewDidLoad];

//Loading the first dynamic library here works fine :)
NSLog(@"Before referencing CASHello in DynamicFramework1");
[self loadCASHelloFromDynamicFramework1];

/*
Loading the second framework will give a message in
the console saying that both classes will be loaded
and referencing the class will result in undefined
behavior.
*/

NSLog(@"Before referencing CASHello in DynamicFramework2");
[self loadCASHelloFromDynamicFramework2];
}

通常，如果我們的應用在運行任何代碼之前就崩潰了，那么最好打開 Dynamic Loader 診斷選項。這可能是部署問題(未捆綁正確的庫)或代碼簽名問題。

Jablotron 崩潰

Jablotron?程序是管理家庭中的警報和檢測器的程序。

這是程序發生崩潰所產生的的崩潰報告，為了便于演示而被截斷：

Incident Identifier: 732438C5-9E5A-48E7-95E2-76C800CDD6D9
CrashReporter Key: 181EC21F-295A-4D13-B14E-8BE1A7DFB5C7
Hardware Model: iPhone3,1
Process: MyJablotron_dev [177]
Path: /var/mobile/Applications/
D3CC3D22-1B0F-4CAF-8F68-71AD3B211CD9/
MyJablotron_dev.app/MyJablotron_dev
Identifier: net.jablonet.myjablotron.staging
Version: 3.3.0.14 (3.3.0.14)
Code Type: ARM
Parent Process: launchd [1]

Date/Time: 2016-05-24T07:59:56Z
Launch Time: 2016-05-24T07:57:08Z
OS Version: iPhone OS 7.1.2 (11D257)
Report Version: 104

Exception Type: SIGBUS
Exception Codes: BUS_ADRALN at 0xcd0b1c
Crashed Thread: 0

Thread 0 Crashed:
0 libswiftCore.dylib 0x011aed64 0xfba000 + 2051428
1 MyJablotron_dev 0x004e7c18 0xb2000 + 4414488
2 libswiftCore.dylib 0x011b007f 0xfba000 + 2056319
3 libswiftCore.dylib 0x011aff73 0xfba000 + 2056051
4 libswiftCore.dylib 0x011adf29 0xfba000 + 2047785
5 libswiftCore.dylib 0x011adf73 0xfba000 + 2047859
6 MyJablotron_dev 0x00614a6c
type metadata accessor for
MyJablotron.CDFM MyJablotron.ChartDataPointStructureLegend>
(ChartThermoPlotSpace.swift:0)
7 MyJablotron_dev 0x00606698
MyJablotron.ChartThermoPlotSpace.init ()
MyJablotron.ChartThermoPlotSpace
(ChartThermoPlotSpace.swift:206)
8 MyJablotron_dev
0x00606c60
MyJablotron.ChartThermoPlotSpace.__allocating_init ()
MyJablotron.ChartThermoPlotSpace
(ChartThermoPlotSpace.swift:0)
9 MyJablotron_dev
0x0048825c
MyJablotron.ChartBase.initWithThermometer
(__ObjC.Thermometer)()
(ChartBase.swift:139)
10 MyJablotron_dev 0x00488034
MyJablotron.ChartBase.initWithSegment (__ObjC.Segment)()
(ChartBase.swift:123)
11 MyJablotron_dev 0x0059186c
MyJablotron.ChartViewController.setupSegment ()()
(ChartViewController.swift:106)
12 MyJablotron_dev 0x0058f374
MyJablotron.ChartViewController.viewDidLoad ()()
(ChartViewController.swift:39)
13 MyJablotron_dev 0x0058f5a4
@objc MyJablotron.ChartViewController.viewDidLoad ()()
(ChartViewController.swift:0)
14 UIKit 0x3227d4ab
-[UIViewController loadViewIfRequired] + 516
15 UIKit 0x3227d269
-[UIViewController view] + 22
16 UIKit 0x3240936b
-[UINavigationController
_startCustomTransition:] + 632
17 UIKit 0x32326d63
-[UINavigationController
_startDeferredTransitionIfNeeded:] + 416
18 UIKit 0x32326b6d
-[UINavigationController
__viewWillLayoutSubviews] + 42
19 UIKit 0x32326b05
-[UILayoutContainerView layoutSubviews] + 182
20 UIKit 0x32278d59
-[UIView(CALayerDelegate)
layoutSublayersOfLayer:] + 378
21 QuartzCore 0x31ef662b
-[CALayer layoutSublayers] + 140
22 QuartzCore 0x31ef1e3b
CA::Layer::layout_if_needed(CA::Transaction*) + 348
23 QuartzCore 0x31ef1ccd
CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 14
24 QuartzCore 0x31ef16df
CA::Context::commit_transaction(CA::Transaction*) + 228
25 QuartzCore 0x31ef14ef
CA::Transaction::commit() + 312
26 QuartzCore 0x31eeb21d
CA::Transaction::observer_callback(__CFRunLoopObserver*,
unsigned long, void*) + 54
27 CoreFoundation 0x2fa27255
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__
+ 18
28 CoreFoundation 0x2fa24bf9
__CFRunLoopDoObservers + 282
29 CoreFoundation 0x2fa24f3b
__CFRunLoopRun + 728
30 CoreFoundation 0x2f98febf
CFRunLoopRunSpecific + 520
31 CoreFoundation 0x2f98fca3
CFRunLoopRunInMode + 104
32 GraphicsServices 0x34895663
GSEventRunModal + 136
33 UIKit 0x322dc14d
UIApplicationMain + 1134
34 MyJablotron_dev 0x002b0683
main (main.m:16)
35 libdyld.dylib 0x3a719ab7
start + 0

我們可以看到崩潰發生在 Swift Core運行時庫中。當我們看到 Apple 的通用代碼崩潰時，通常表明濫用 API 。在這些情況下，我們希望看到一個描述性錯誤。

在此示例中，我們得到總線對齊錯誤。Apple 的庫代碼錯誤地訪問了 CPU 架構的內存地址。

這令人驚喜。有時，當我們使用高級特性或設置編譯器優化設置時，我們可能會在特殊情況或較少使用的代碼路徑中觸發錯誤。

我們看到問題出在對象初始化期間：

6 MyJablotron_dev 0x00614a6c
type metadata accessor for
MyJablotron.CDFM MyJablotron.ChartDataPointStructureLegend>
(ChartThermoPlotSpace.swift:0)
7 MyJablotron_dev 0x00606698
MyJablotron.ChartThermoPlotSpace.init ()
MyJablotron.ChartThermoPlotSpace
(ChartThermoPlotSpace.swift:206)
8 MyJablotron_dev 0x00606c60
MyJablotron.ChartThermoPlotSpace.__allocating_init ()
MyJablotron.ChartThermoPlotSpace (ChartThermoPlotSpace.swift:0)

“元數據訪問器”短語很有趣，因為它暗示我們正在運行編譯器生成的代碼，而不是我們直接編寫的代碼。也許，作為一種解決方法，我們可以簡化代碼以使用更簡單的語言功能。

在這里，我們的目標是通過采用ChartThermoPlotSpace類并簡化它來編寫一個簡單的測試用例，直到找到發生崩潰的必要代碼為止。

蘋果通過更新其編譯器來糾正 Swift Generics 錯誤，從而解決了該崩潰問題。

總結

以上是生活随笔為你收集整理的内存泄漏MobX State Tree_[译]iOS Crash Dump Analysis 错误的内存崩溃的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。