如何调试仅在iPhone应用程序的发布目标上出现的EXC_BAD_ACCESS? [英] How to debug EXC_BAD_ACCESS that occurs only on release target for an iPhone app?

查看:104
本文介绍了如何调试仅在iPhone应用程序的发布目标上出现的EXC_BAD_ACCESS?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在开发一个iPhone应用程序。我有一个 EXC_BAD_ACCESS ,它只在发布目标中出现;当我构建调试目标时,不会发生异常。但是,当我将 NSZombieEnabled 环境变量设置为 YES 时,我仍然得到 EXC_BAD_ACCESS 没有更多信息。执行释放目标时是否可以使用 NSZombieEnabled 来工作?我不明白为什么不这样做,因为gdb在两种情况下都运行...



更新:这里是打印输出的顶部

$ p $ #0 0x33369ebc in objc_msgSend()
#1 0x3144f968 in - [EAInputStream _streamEventTrigger]()$ b)在CFRunLoopRunSpecific()
#4中的0x338ae3a6 0x343feb在CFRunLoopRunInMode()
#5 0x32ed6966中 - [NSRunLoop(NSRunLoop)runMode:beforeDate: / Users / robertmoretti / Documents / XXXXXXX / IOStreamDelegate中的[]()
#6 0x00005b06 in - [IOStreamDelegate removeMsg:](self = 0x142cc0,_cmd =< value temporarily unavailable,due to optimizations>,message = 0x2fffe544) .m:191

这是来自顶部objc_msgSend调用的gdb会话:

 (gdb)p / x $ r0 
$ 6 = 0x3100000
(gdb)x / s $ r1
0x32d7cff8:release
(gdb)反汇编$ pc
函数汇编代码转储objc_msgSend:
0 x33369ea8< objc_msgSend + 0>:teq r0,#0; 0x0
0x33369eac< objc_msgSend + 4>:moveq r1,#0; 0x0
0x33369eb0< objc_msgSend + 8>:bxeq lr
0x33369eb4< objc_msgSend + 12> ;: push {r3,r4,r5,r6}
0x33369eb8< objc_msgSend + 16> ;:ldr r4,[r0]
0x33369ebc< objc_msgSend + 20> ;: ldr r5,[r4,#8]
0x33369ec0< objc_msgSend + 24>:ldr r6,[r5]
0x33369ec4< ; objc_msgSend + 28>:add r3,r5,#8; 0x8
0x33369ec8< objc_msgSend + 32> ;:和r5,r6,r1,lsr#2
0x33369ecc< objc_msgSend + 36>:ldr r4,[r3,r5,lsl#2]
0x33369ed0< objc_msgSend + 40>:teq r4,#0; 0x0
0x33369ed4< objc_msgSend + 44> ;: add r5,r5,#1; 0x1
0x33369ed8< objc_msgSend + 48>:beq 0x33369efc< objc_msgSend + 84>
0x33369edc< objc_msgSend + 52> ;: ldr r12,[r4]
0x33369ee0< objc_msgSend + 56> ;: teq r1,r12
0x33369ee4< objc_msgSend + 60>:和r5,r5 ,r6
0x33369ee8< objc_msgSend + 64>:bne 0x33369ecc< objc_msgSend + 36>
0x33369eec< objc_msgSend + 68> ;: ldr r12,[r4,#8]
0x33369ef0< objc_msgSend + 72> ;: teq r4,r4
0x33369ef4< objc_msgSend + 76>:pop {r3,r4,r5,r6}
0x33369ef8< objc_msgSend + 80> ;: bx r12
0x33369efc< objc_msgSend + 84>:pop {r3,r4,r5,r6}
0x33369f00 < objc_msgSend + 88>:b 0x33369f04< objc_msgSend_uncached>
汇编器转储结束。
(gdb)p / x * $ r0
$ 9 = 0x0

0x33369ebc< objc_msgSend + 20>:ldr r5,[r4,#8] 行上发生异常。 r4 刚刚被赋予了由 r0 指向的值,恰好为0.我想知道什么是假设位于 0x3100000 的内存区域。下面是该区域的内存转储:

$ $ $ $ $ $ c $(gdb)x / 256w 0x3100000
0x3100000:0x00000000 0x0000a293 0xaa650505 0x00000000
0x3100010:0x0000a294 0xaa670505 0x00000000 0x0000a295
0x3100020:0xaa690505 0x00000000 0x0000a296 0xaa6b0505
0x3100030:0x00000000 0x0000a297 0xaa6d0505 0x00000000
0x3100040:0x0000a298 0xaa6f0505 0x00000000 0x0000a299
0x3100050:0xaa710505 0x00000000 0x0000a29a 0xaa730505
0x3100060:00000000 0x0000a29b 0xaa750505 00000000
0x3100070:0x0000a29c 0xaa770505 00000000 0x0000a29d
0x3100080:0xaa790505 00000000 0x0000a29e 0xaa7b0505
0x3100090:00000000 0x0000a29f 0xaa7d0505 00000000
0x31000a0:0x0000a2a0 0xaa7f0505 00000000 0x0000a2a1
0x31000b0:0xaa810505 0x00000000 0x0000a2a2 0xaa830505
0x31000c0:0x00000000 0x0000a2a3 0xaa850505 0x00000000
0x31000d0:0x0000a2a4 0xaa870505 0x00000000 0x0000a2a5
0x31000e0: 0xaa890505 0x00000000 0x0000a2a6 0xaa8b0505
0x31000f0:0x00000000 0x0000a2a7 0xaa8d0505 0x00000000
0x3100100:0x0000a2a8 0xaa8f0505 0x00000000 0x0000a2a9
0x3100110:0xaa910505 0x00000000 0x0000a2aa 0xaa930505
0x3100120:0x00000000 0x0000a2ab 0xaa950505 0x00000000
0x3100130: 0x0000a2ac 0xaa970505 0x00000000 0x0000a2ad
0x3100140:0xaa990505 0x00000000 0x0000a2ae 0xaa9b0505
0x3100150:0x00000000 0x0000a2af 0xaa9d0505 0x00000000
0x3100160:0x0000a2b0 0xaa9f0505 0x00000000 0x0000a2b1
0x3100170:0xaaa10505 0x00000000 0x0000a2b2 0xaaa30505
0x3100180: 0x00000000 0x0000a2b3 0xaaa50505 0x0000a2b4 0x3100190:0x0000a2b4 0xaaa70505 0x00000000 0x0000a2b5
0x31001a0:0xaaa90505 0x00000000 0x0000a2b6 0xaaab0505
0x31001b0:0x00000000 0x0000a2b7 0xaa001 0x000000000
0x31001c0:0x0000a2b8 0xaaaf0505 0x00000000 0x0000a2b9
0x31001d0: 0xaab10505 0x00000000 0x0000a2ba 0xaa b30505
0x31001e0:0x00000000 0x0000a2bb 0xaab50505 0x00000000
0x31001f0:0x0000a2bc 0xaab70505 0x00000000 0x0000a2bd
0x3100200:0xaab90505 0x00000000 0x0000a2be 0xaabb0505
0x3100210:0x00000000 0x0000a2bf 0xaabd0505 0x00000000
0x3100220:0x0000a2c0 0xaabf0505 0x00000000 0x0000a2c1
0x3100230:0xaac10505 0x00000000 0x0000a2c2 0xaac30505
0x3100240:0x00000000 0x0000a2c3 0xaac50505 0x00000000
0x3100250:0x0000a2c4 0xaac70505 0x00000000 0x0000a2c5
0x3100260:0xaac90505 0x00000000 0x0000a2c6 0xaacb0505
0x3100270:0x00000000 0x0000a2c7 0xaacd0505 0x00000000
0x3100280:0x0000a2c8 0xaacf0505 0x00000000 0x0000a2c9
0x3100290:0xaad10505 0x00000000 0x0000a2ca 0xaad30505
0x31002a0:0x00000000 0x0000a2cb 0xaad50505 0x00000000
0x31002b0:0x0000a2cc 0xaad70505 0x00000000 0x0000a2cd
0x31002c0:0xaad90505 0x00000000 0x0000a2ce 0xaadb0505
0x31002d0:0x00000000 0x00 00a2cf 0xaadd0505 00000000
0x31002e0:0x0000a2d0 0xaadf0505 00000000 0x0000a2d1
0x31002f0:0xaae10505 00000000 0x0000a2d2 0xaae30505
0x3100300:00000000 0x0000a2d3 0xaae50505 00000000
0x3100310:0x0000a2d4 0xaae70505 00000000 0x0000a2d5
0x3100320:0xaae90505 0x00000000 0x0000a2d6 0xaaeb0505
0x3100330:0x00000000 0x0000a2d7 0xaaed0505 0x00000000
0x3100340:0x0000a2d8 0xaaef0505 0x00000000 0x0000a2d9
0x3100350:0xaaf10505 0x00000000 0x0000a2da 0xaaf30505
0x3100360:0x00000000 0x0000a2db 0xaaf50505 0x00000000
0x3100370:0x0000a2dc 0xaaf70505 00000000 0x0000a2dd
0x3100380:0xaaf90505 00000000 0x0000a2de 0xaafb0505
0x3100390:00000000 0x0000a2df 0xaafd0505 00000000
0x31003a0:0x0000a2e0 0xab050505 00000000 0x0000a2e1
0x31003b0:0xab070505 00000000 0x0000a2e2 0xab090505
0x31003c0:00000000 0x0000a2e3 0xab0b0505 0x00000000
0x31 003d0:0x0000a2e4 0xab0d0505 0x00000000 0x0000a2e5
0x31003e0:0xab0f0505 0x00000000 0x0000a2e6 0xab110505
0x31003f0:0x00000000 0x0000a2e7 0xab130505 0x00000000

我真的不知道还有什么要尝试的;希望有更多iphone经验的人能够将此内存识别为有意义的内容。

更新2:我刚发现问题只发生当编译-O2,-O3和-Os时。不知道这意味着什么。

解决方案在 objc_msgSend 中, r0 包含一个指向消息接收者的指针。当您的应用尝试加载接收者指向的内容时,它会崩溃。最可能的解释是,您要么传递一个尚未初始化的对象,要么已经释放一个对象,但还有其他可能。

也可能想看看所以你坠毁在objc_msgSend ;它是关于英特尔OS X平台的,但其中大部分也适用于iPhone操作系统。


I'm developing an iPhone application. I have an EXC_BAD_ACCESS that occurs only in the release target; when I build the debug target the exception does not occur. However, when I set the NSZombieEnabled environment variable to YES, I still get the EXC_BAD_ACCESS with no further information. Is it even possible for NSZombieEnabled to work when executing the release target? I don't see why not, since gdb is running in both cases...

Update: here is a printout of the top of the stack:

#0  0x33369ebc in objc_msgSend ()
#1  0x3144f968 in -[EAInputStream _streamEventTrigger] ()
#2  0x3144fe78 in __streamEventTrigger ()
#3  0x338ae3a6 in CFRunLoopRunSpecific ()
#4  0x338adc1e in CFRunLoopRunInMode ()
#5  0x32ed6966 in -[NSRunLoop(NSRunLoop) runMode:beforeDate:] ()
#6  0x00005b06 in -[IOStreamDelegate removeMsg:] (self=0x142cc0, _cmd=<value temporarily unavailable, due to optimizations>, message=0x2fffe544) at /Users/robertmoretti/Documents/XXXXXXX/IOStreamDelegate.m:191

Here is a gdb session from inside the objc_msgSend call at the top:

(gdb) p/x $r0
$6 = 0x3100000
(gdb) x/s $r1
0x32d7cff8:  "release"
(gdb) disassemble $pc
Dump of assembler code for function objc_msgSend:
0x33369ea8 <objc_msgSend+0>:    teq r0, #0  ; 0x0
0x33369eac <objc_msgSend+4>:    moveq   r1, #0  ; 0x0
0x33369eb0 <objc_msgSend+8>:    bxeq    lr
0x33369eb4 <objc_msgSend+12>:   push    {r3, r4, r5, r6}
0x33369eb8 <objc_msgSend+16>:   ldr r4, [r0]
0x33369ebc <objc_msgSend+20>:   ldr r5, [r4, #8]
0x33369ec0 <objc_msgSend+24>:   ldr r6, [r5]
0x33369ec4 <objc_msgSend+28>:   add r3, r5, #8  ; 0x8
0x33369ec8 <objc_msgSend+32>:   and r5, r6, r1, lsr #2
0x33369ecc <objc_msgSend+36>:   ldr r4, [r3, r5, lsl #2]
0x33369ed0 <objc_msgSend+40>:   teq r4, #0  ; 0x0
0x33369ed4 <objc_msgSend+44>:   add r5, r5, #1  ; 0x1
0x33369ed8 <objc_msgSend+48>:   beq 0x33369efc <objc_msgSend+84>
0x33369edc <objc_msgSend+52>:   ldr r12, [r4]
0x33369ee0 <objc_msgSend+56>:   teq r1, r12
0x33369ee4 <objc_msgSend+60>:   and r5, r5, r6
0x33369ee8 <objc_msgSend+64>:   bne 0x33369ecc <objc_msgSend+36>
0x33369eec <objc_msgSend+68>:   ldr r12, [r4, #8]
0x33369ef0 <objc_msgSend+72>:   teq r4, r4
0x33369ef4 <objc_msgSend+76>:   pop {r3, r4, r5, r6}
0x33369ef8 <objc_msgSend+80>:   bx  r12
0x33369efc <objc_msgSend+84>:   pop {r3, r4, r5, r6}
0x33369f00 <objc_msgSend+88>:   b   0x33369f04 <objc_msgSend_uncached>
End of assembler dump.
(gdb) p/x *$r0
$9 = 0x0

The exception occurs on the line 0x33369ebc <objc_msgSend+20>: ldr r5, [r4, #8]. r4 has just been given the value pointed to by r0, which happens to be 0. I am wondering what is supposed to be in the memory region of 0x3100000. Here's a memory dump of that area:

(gdb) x/256w 0x3100000
0x3100000:  0x00000000  0x0000a293  0xaa650505  0x00000000
0x3100010:  0x0000a294  0xaa670505  0x00000000  0x0000a295
0x3100020:  0xaa690505  0x00000000  0x0000a296  0xaa6b0505
0x3100030:  0x00000000  0x0000a297  0xaa6d0505  0x00000000
0x3100040:  0x0000a298  0xaa6f0505  0x00000000  0x0000a299
0x3100050:  0xaa710505  0x00000000  0x0000a29a  0xaa730505
0x3100060:  0x00000000  0x0000a29b  0xaa750505  0x00000000
0x3100070:  0x0000a29c  0xaa770505  0x00000000  0x0000a29d
0x3100080:  0xaa790505  0x00000000  0x0000a29e  0xaa7b0505
0x3100090:  0x00000000  0x0000a29f  0xaa7d0505  0x00000000
0x31000a0:  0x0000a2a0  0xaa7f0505  0x00000000  0x0000a2a1
0x31000b0:  0xaa810505  0x00000000  0x0000a2a2  0xaa830505
0x31000c0:  0x00000000  0x0000a2a3  0xaa850505  0x00000000
0x31000d0:  0x0000a2a4  0xaa870505  0x00000000  0x0000a2a5
0x31000e0:  0xaa890505  0x00000000  0x0000a2a6  0xaa8b0505
0x31000f0:  0x00000000  0x0000a2a7  0xaa8d0505  0x00000000
0x3100100:  0x0000a2a8  0xaa8f0505  0x00000000  0x0000a2a9
0x3100110:  0xaa910505  0x00000000  0x0000a2aa  0xaa930505
0x3100120:  0x00000000  0x0000a2ab  0xaa950505  0x00000000
0x3100130:  0x0000a2ac  0xaa970505  0x00000000  0x0000a2ad
0x3100140:  0xaa990505  0x00000000  0x0000a2ae  0xaa9b0505
0x3100150:  0x00000000  0x0000a2af  0xaa9d0505  0x00000000
0x3100160:  0x0000a2b0  0xaa9f0505  0x00000000  0x0000a2b1
0x3100170:  0xaaa10505  0x00000000  0x0000a2b2  0xaaa30505
0x3100180:  0x00000000  0x0000a2b3  0xaaa50505  0x00000000
0x3100190:  0x0000a2b4  0xaaa70505  0x00000000  0x0000a2b5
0x31001a0:  0xaaa90505  0x00000000  0x0000a2b6  0xaaab0505
0x31001b0:  0x00000000  0x0000a2b7  0xaaad0505  0x00000000
0x31001c0:  0x0000a2b8  0xaaaf0505  0x00000000  0x0000a2b9
0x31001d0:  0xaab10505  0x00000000  0x0000a2ba  0xaab30505
0x31001e0:  0x00000000  0x0000a2bb  0xaab50505  0x00000000
0x31001f0:  0x0000a2bc  0xaab70505  0x00000000  0x0000a2bd
0x3100200:  0xaab90505  0x00000000  0x0000a2be  0xaabb0505
0x3100210:  0x00000000  0x0000a2bf  0xaabd0505  0x00000000
0x3100220:  0x0000a2c0  0xaabf0505  0x00000000  0x0000a2c1
0x3100230:  0xaac10505  0x00000000  0x0000a2c2  0xaac30505
0x3100240:  0x00000000  0x0000a2c3  0xaac50505  0x00000000
0x3100250:  0x0000a2c4  0xaac70505  0x00000000  0x0000a2c5
0x3100260:  0xaac90505  0x00000000  0x0000a2c6  0xaacb0505
0x3100270:  0x00000000  0x0000a2c7  0xaacd0505  0x00000000
0x3100280:  0x0000a2c8  0xaacf0505  0x00000000  0x0000a2c9
0x3100290:  0xaad10505  0x00000000  0x0000a2ca  0xaad30505
0x31002a0:  0x00000000  0x0000a2cb  0xaad50505  0x00000000
0x31002b0:  0x0000a2cc  0xaad70505  0x00000000  0x0000a2cd
0x31002c0:  0xaad90505  0x00000000  0x0000a2ce  0xaadb0505
0x31002d0:  0x00000000  0x0000a2cf  0xaadd0505  0x00000000
0x31002e0:  0x0000a2d0  0xaadf0505  0x00000000  0x0000a2d1
0x31002f0:  0xaae10505  0x00000000  0x0000a2d2  0xaae30505
0x3100300:  0x00000000  0x0000a2d3  0xaae50505  0x00000000
0x3100310:  0x0000a2d4  0xaae70505  0x00000000  0x0000a2d5
0x3100320:  0xaae90505  0x00000000  0x0000a2d6  0xaaeb0505
0x3100330:  0x00000000  0x0000a2d7  0xaaed0505  0x00000000
0x3100340:  0x0000a2d8  0xaaef0505  0x00000000  0x0000a2d9
0x3100350:  0xaaf10505  0x00000000  0x0000a2da  0xaaf30505
0x3100360:  0x00000000  0x0000a2db  0xaaf50505  0x00000000
0x3100370:  0x0000a2dc  0xaaf70505  0x00000000  0x0000a2dd
0x3100380:  0xaaf90505  0x00000000  0x0000a2de  0xaafb0505
0x3100390:  0x00000000  0x0000a2df  0xaafd0505  0x00000000
0x31003a0:  0x0000a2e0  0xab050505  0x00000000  0x0000a2e1
0x31003b0:  0xab070505  0x00000000  0x0000a2e2  0xab090505
0x31003c0:  0x00000000  0x0000a2e3  0xab0b0505  0x00000000
0x31003d0:  0x0000a2e4  0xab0d0505  0x00000000  0x0000a2e5
0x31003e0:  0xab0f0505  0x00000000  0x0000a2e6  0xab110505
0x31003f0:  0x00000000  0x0000a2e7  0xab130505  0x00000000

I don't really know what else to try; hopefully someone with more iphone experience will be able to recognize this memory as something meaningful.

Update 2: I just discovered that the problem only occurs when compiling with -O2, -O3, and -Os. Not sure what that implies.

解决方案

In objc_msgSend, r0 contains a pointer to the receiver of the message. Your app is crashing when it tries to load something pointed to by the receiver. The most likely explanation is that you are either messaging an object that hasn't been initialized, or an object that has already been freed, but there are other possibilities.

You also may want to have a look at "So you crashed in objc_msgSend"; it's written about the Intel OS X platform, but much of it also applies to the iPhone OS.

这篇关于如何调试仅在iPhone应用程序的发布目标上出现的EXC_BAD_ACCESS?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆