iOS dealloc中初始化weak指针崩溃防护
序
开发过程中，总是难免写出一些bug导致崩溃，即使有些崩溃原因显而易见，我们也很难完全避免, 这时候就要通过一些技术手段来避免问题。
今天想给大家分享一下关于在dealloc中初始化一个指向自身的weak指针产生崩溃的防护方案。
在某些类的dealloc中我们会去做一些清理工作，这时候可能就会去初始化一个指向自身的weak指针，尤其是在使用懒加载的时候。
问题分析
这段代码在走到dealloc的时候是必崩的。
#import "WeakTestObj.h" @implementation WeakTestObj - (void)dealloc {
__weak typeof(self) weakSelf = self;
} @end
原因呢我们可以看一下崩溃堆栈和输出的错
很明显，当我们在dealloc初始化指向自身的weak指针时，在objc_initWeak中发生了错误，原因是因为该对象正在被释放当中。
但为何对象在释放时初始化指向自身的weak指针会崩溃呢，我们可以通过runtime源码(https://opensource.apple.com/tarballs/objc4/)进一步分析。
我们先通过Xcode看一下崩溃时的汇编代码
libobjc.A.dylib`objc_initWeak:
0x7fff2019209e <+0>: pushq %rbp
0x7fff2019209f <+1>: movq %rsp, %rbp
0x7fff201920a2 <+4>: pushq %r15
0x7fff201920a4 <+6>: pushq %r14
0x7fff201920a6 <+8>: pushq %r13
0x7fff201920a8 <+10>: pushq %r12
0x7fff201920aa <+12>: pushq %rbx
0x7fff201920ab <+13>: subq $0x28, %rsp
0x7fff201920af <+17>: testq %rsi, %rsi
0x7fff201920b2 <+20>: je 0x7fff20192227 ; <+393>
0x7fff201920b8 <+26>: movq %rsi, %r13
0x7fff201920bb <+29>: movq %rdi, -0x40(%rbp)
0x7fff201920bf <+33>: movabsq $0x7ffffffffff8, %r14 ; imm = 0x7FFFFFFFFFF8
0x7fff201920c9 <+43>: movl %r13d, %eax
0x7fff201920cc <+46>: shrl $0x9, %eax
0x7fff201920cf <+49>: movl %r13d, %r12d
0x7fff201920d2 <+52>: shrl $0x4, %r12d
0x7fff201920d6 <+56>: xorl %eax, %r12d
0x7fff201920d9 <+59>: andl $0x3f, %r12d
0x7fff201920dd <+63>: shlq $0x6, %r12
0x7fff201920e1 <+67>: leaq 0x5fea34d8(%rip), %rax ; (anonymous namespace)::SideTablesMap
0x7fff201920e8 <+74>: leaq (%rax,%r12), %r15
0x7fff201920ec <+78>: movq %r15, %rdi
0x7fff201920ef <+81>: movl $0x50000, %esi ; imm = 0x50000
0x7fff201920f4 <+86>: callq 0x7fff201952b4 ; symbol stub for: os_unfair_lock_lock_with_options
0x7fff201920f9 <+91>: movq %r13, %rax
0x7fff201920fc <+94>: shrq $0x3c, %rax
0x7fff20192100 <+98>: movq %rax, -0x38(%rbp)
0x7fff20192104 <+102>: movq %r13, %rax
0x7fff20192107 <+105>: shrq $0x31, %rax
0x7fff2019210b <+109>: andl $0x7f8, %eax ; imm = 0x7F8
0x7fff20192110 <+114>: addq 0x64853871(%rip), %rax ; (void *)0x00007fff80030870: objc_debug_taggedpointer_ext_classes
0x7fff20192117 <+121>: movq %rax, -0x30(%rbp)
0x7fff2019211b <+125>: xorl %eax, %eax
0x7fff2019211d <+127>: movq %r13, %rcx
0x7fff20192120 <+130>: testq %r13, %r13
0x7fff20192123 <+133>: js 0x7fff20192192 ; <+244>
0x7fff20192125 <+135>: movq (%rcx), %rbx
0x7fff20192128 <+138>: cmpq %rax, %rbx
0x7fff2019212b <+141>: je 0x7fff201921ba ; <+284>
0x7fff20192131 <+147>: movq (%rbx), %rax
0x7fff20192134 <+150>: leaq -0x1(%rax), %rcx
0x7fff20192138 <+154>: cmpq $0xf, %rcx
0x7fff2019213c <+158>: jb 0x7fff2019214d ; <+175>
0x7fff2019213e <+160>: movq 0x20(%rbx), %rcx
0x7fff20192142 <+164>: andq %r14, %rcx
0x7fff20192145 <+167>: testb $0x1, (%rcx)
0x7fff20192148 <+170>: je 0x7fff2019214d ; <+175>
0x7fff2019214a <+172>: movq %rbx, %rax
0x7fff2019214d <+175>: movq 0x20(%rax), %rax
0x7fff20192151 <+179>: andq %r14, %rax
0x7fff20192154 <+182>: testb $0x20, 0x3(%rax)
0x7fff20192158 <+186>: jne 0x7fff201921ba ; <+284>
0x7fff2019215a <+188>: movq %r15, %rdi
0x7fff2019215d <+191>: callq 0x7fff201952ba ; symbol stub for: os_unfair_lock_unlock
0x7fff20192162 <+196>: leaq 0x5fe9f1d3(%rip), %rdi ; runtimeLock
0x7fff20192169 <+203>: movl $0x50000, %esi ; imm = 0x50000
0x7fff2019216e <+208>: callq 0x7fff201952b4 ; symbol stub for: os_unfair_lock_lock_with_options
0x7fff20192173 <+213>: movq %rbx, %rdi
0x7fff20192176 <+216>: movq %r13, %rsi
0x7fff20192179 <+219>: xorl %edx, %edx
0x7fff2019217b <+221>: callq 0x7fff2017bcdc ; initializeAndMaybeRelock(objc_class*, objc_object*, mutex_tt<false>&, bool)
0x7fff20192180 <+226>: movq %r15, %rdi
0x7fff20192183 <+229>: movl $0x50000, %esi ; imm = 0x50000
0x7fff20192188 <+234>: callq 0x7fff201952b4 ; symbol stub for: os_unfair_lock_lock_with_options
0x7fff2019218d <+239>: movq %rbx, %rax
0x7fff20192190 <+242>: jmp 0x7fff2019211d ; <+127>
0x7fff20192192 <+244>: movq -0x38(%rbp), %rcx
0x7fff20192196 <+248>: leaq 0x5fe9e653(%rip), %rdx ; objc_debug_taggedpointer_classes
0x7fff2019219d <+255>: movq (%rdx,%rcx,8), %rbx
0x7fff201921a1 <+259>: movq -0x30(%rbp), %rcx
0x7fff201921a5 <+263>: leaq 0x5fe9e504(%rip), %rdx ; (void *)0x00007fff80030688: __NSUnrecognizedTaggedPointer
0x7fff201921ac <+270>: cmpq %rdx, %rbx
0x7fff201921af <+273>: jne 0x7fff20192128 ; <+138>
0x7fff201921b5 <+279>: jmp 0x7fff20192125 ; <+135>
0x7fff201921ba <+284>: leaq 0x5fea33ff(%rip), %rax ; (anonymous namespace)::SideTablesMap
0x7fff201921c1 <+291>: leaq 0x20(%r12,%rax), %rdi
0x7fff201921c6 <+296>: movq %rax, %r12
0x7fff201921c9 <+299>: movq %r13, %rsi
0x7fff201921cc <+302>: movq -0x40(%rbp), %r14
0x7fff201921d0 <+306>: movq %r14, %rdx
0x7fff201921d3 <+309>: movl $0x1, %ecx
0x7fff201921d8 <+314>: callq 0x7fff201905ff ; weak_register_no_lock
-> 0x7fff201921dd <+319>: movq %rax, %rbx
0x7fff201921e0 <+322>: testq %rax, %rax
崩溃发生在85行处，然后我们往上查找，可以看到是在weak_register_no_lock 这个方法内部发生了崩溃。
id weak_register_no_lock(weak_table_t *weak_table, id referent_id,
id *referrer_id, WeakRegisterDeallocatingOptions deallocatingOptions)
{
objc_object *referent = (objc_object *)referent_id;
objc_object **referrer = (objc_object **)referrer_id;
if (referent->isTaggedPointerOrNil()) return referent_id;
// ensure that the referenced object is viable
if (deallocatingOptions == ReturnNilIfDeallocating ||
deallocatingOptions == CrashIfDeallocating) {
bool deallocating;
if (!referent->ISA()->hasCustomRR()) {
deallocating = referent->rootIsDeallocating();
}
else {
// Use lookUpImpOrForward so we can avoid the assert in
// class_getInstanceMethod, since we intentionally make this
// callout with the lock held.
auto allowsWeakReference = (BOOL(*)(objc_object *, SEL))
lookUpImpOrForwardTryCache((id)referent, @selector(allowsWeakReference),
referent->getIsa());
if ((IMP)allowsWeakReference == _objc_msgForward) {
return nil;
}
deallocating =
! (*allowsWeakReference)(referent, @selector(allowsWeakReference));
}
if (deallocating) {
if (deallocatingOptions == CrashIfDeallocating) {
_objc_fatal("Cannot form weak reference to instance (%p) of "
"class %s. It is possible that this object was "
"over-released, or is in the process of deallocation.",
(void*)referent, object_getClassName((id)referent));
} else {
return nil;
}
}
}
// now remember it and where it is being stored
weak_entry_t *entry;
if ((entry = weak_entry_for_referent(weak_table, referent))) {
append_referrer(entry, referrer);
}
else {
weak_entry_t new_entry(referent, referrer);
weak_grow_maybe(weak_table);
weak_entry_insert(weak_table, &new_entry);
}
// Do not set *referrer. objc_storeWeak() requires that the
// value not change.
return referent_id;
}
可以看一下第31行代码处，如果自身在dealloc中并且deallocatingOptions == CrashIfDeallocating，则打印错误日志并退出。
系统为什么要这么做呢？ 因为在对象dealloc时，系统会去查找对象的弱引用表，并把所有指向该对象的弱引用置为nil，如果我们在对象的dealloc中去初始化一个指向该对象的弱引用指针，很明显这是会产生冲突的。
现在我们已经知道了崩溃产生的具体原因和位置，接下来就开始思考如何防护。
在37行代码处我们可以看到，如果 deallocatingOptions != CrashIfDeallocating系统直接返回了nil，此时不发生崩溃。因此我们也可以通过同样的操作来避免崩溃的出现。
在到崩溃发生前，其实经过了好几个C方法的调用，分别是 objc_initWeak,
storeWeak, weak_register_no_lock，理论上我们hook这当中任意一个方法都是可以的。hook之后判断一下该对象是否正在释放当中，如果是的话，直接返回nil。
至于如何判断是否正在释放中，我们也可以通过runtime的源码找到答案。
本人采用的是NSObjct的一个私有方法。
- (BOOL)_isDeallocating {
return _objc_rootIsDeallocating(self);
}
解决方案
接下来看一下具体的实现代码
#import "fishhook.h" //fishhook,请自行搜索
//分类暴露私有方法
@interface NSObject (runtimePrivate)
- (BOOL)_isDeallocating;
@end
static id(*sys_objc_initWeak)(id _Nullable * _Nonnull location, id _Nullable obj);
id _Nullable
aigis_objc_initWeak(id _Nullable * _Nonnull location, id _Nullable obj) {
//判断是否正在释放
if ([obj respondsToSelector:@selector(_isDeallocating)]) {
if([obj _isDeallocating]) {
return nil;
}
}
//调用系统的initWeak
return sys_objc_initWeak(location,obj);
}
//调用此方法进行hook
void start_objec_weak_defender() {
//hook objc_initWeak 方法
struct rebinding rebindObj;
rebindObj.name = "objc_initWeak";
rebindObj.replacement = aigis_objc_initWeak;
rebindObj.replaced = (void *)&sys_objc_initWeak;
struct rebinding rebindings[] = {rebindObj};
int result = rebind_symbols(rebindings, 1);
}
此外，细心的朋友们应该也注意到另一种方案，hook weak_register_no_lock之后，直接修改deallocatingOptions参数。（ps: 此方案未实现过，感兴趣的朋友们可以自行探索）
weak_register_no_lock(weak_table_t *weak_table, id referent_id, id *referrer_id, WeakRegisterDeallocatingOptions deallocatingOptions)
