次のような SIGSEGV/SEGV_ACCERR クラッシュがあります。
Thread 0 Crashed:
0 libobjc.A.dylib 0x39c69f2a _objc_release + 10
1 CoreFoundation 0x31cf4441 __CFAutoreleasePoolPop + 17
2 Foundation 0x326c8185 __NSThreadPerformPerform + 605
3 CoreFoundation 0x31d86683 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15
4 CoreFoundation 0x31d85ee9 __CFRunLoopDoSources0 + 213
5 CoreFoundation 0x31d84cb7 __CFRunLoopRun + 647
6 CoreFoundation 0x31cf7ebd _CFRunLoopRunSpecific + 357
7 CoreFoundation 0x31cf7d49 _CFRunLoopRunInMode + 105
8 GraphicsServices 0x358c32eb _GSEventRunModal + 75
9 UIKit 0x33c0d301 _UIApplicationMain + 1121
10 MyApp 0x0007471b main (main.m:15)
問題は、SEGV_ACCERR アドレスが常に無効であることです。次のアドレスを見たことがあります: 0xa2142302、、、、0x51e9d281など。私の理解では、内部の SEGV_ACCERR アドレスは、解放されるオブジェクトまたはそのクラス オブジェクトへのポインターである必要があります。ご覧のとおり、上記の例のアドレスの最初の 3 つはずれており ( が16 バイトで整列されたアドレスのみを返す場合)、最後の 1 つは明らかに偽物です。0x11e1af4e0x10_objc_release()malloc()
クラッシュは で発生し__CFAutoreleasePoolPop()ます。これは、偽のポインタが何らかの形で自動解放プールによって収集されたことを示しています。私の理解では、ポインターが自動解放プールによって収集される唯一の方法は、-autoreleaseメッセージを受信した有効な Obj-C オブジェクトであることです。
私の前提が両方とも正しい場合、メモリ破損の悪いケースが発生しています。つまり、有効な Obj-C オブジェクトが受信-autoreleaseされ、自動解放プールに入り、そのメモリ位置がガベージで上書きされ、自動解放プールがそれを解放しようとしたときに、無効なポインターを逆参照しました。
このようにメモリを破損させる可能性のあるバグにはどのようなものがありますか? memcpy()のような関数、スタック オーバーフロー、バッファ オーバーフローが考えられます。他に何を探すことができますか？
以下は、スレッド状態の典型的な例です。SEGV_ACCERR アドレスは常に+ 16 r1、常に+ 48 ですが、私が言えるのはそれだけです。r10 0xa3a3a3a3r6r4
Exception Type: SIGSEGV
Exception Codes: SEGV_ACCERR at 0x51e9d281
...
Thread 0 crashed with ARM Thread State:
r0: 0x1e865730 r1: 0x51e9d271 r2: 0x00000002 r3: 0xc4d443fb
r4: 0x1e0ff000 r5: 0x3bc64bd0 r6: 0x1e0ff030 r7: 0x2fdbdddc
r8: 0x1e0ff030 r9: 0x0015991c r10: 0xa3a3a3a3 r11: 0x00000088
ip: 0x3bc5f800 sp: 0x2fdbddbc lr: 0x39c69489 pc: 0x39c69f2a
cpsr: 0x20000030
残念ながら、クラッシュを自分で再現することはできません。すべてのレポートは実際のユーザーからのものです。どんなアイデアでも大歓迎です。