没有calltrace（使用ARC）的过度释放，主要的错误访问 [英] over-release without a calltrace (using ARC), bad acces in main
问题描述
我最近转换为使用ARC。但是，我现在有一个奇怪的崩溃，而且崩溃日志真的没有用。在我的一个应用程序初始化过程中（从服务器获取数据，解析它，设置视图），我得到一个bad_access。这是来自设备的错误日志：
I've recently converted to using ARC. However, i'm having a weird crash now, and the crashlogs are really unhelpful. During one of my application initialization processes (getting data from server, parsing it, setting up views), i get a bad_access. This is the error log from the device:
Incident Identifier: 7CE05452-7C5D-424A-8529-AE7B17C9FEBC
CrashReporter Key: b743ede30ce737293cf7444f67bb8a7b590c2fd9
Hardware Model: iPhone3,1
Process: BoreBeta [231]
Path: /var/mobile/Applications/52A15437-459A-4160-95C4-BF5DF5C98C15/BoreBeta.app/BoreBeta
Identifier: BoreBeta
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2011-08-18 14:53:41.800 +0200
OS Version: iPhone OS 5.0 (9A5288d)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x80000004
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 CoreFoundation 0x3758e380 CFRelease + 28
1 CoreFoundation 0x375a93ec -[__NSArrayM dealloc] + 116
2 libobjc.A.dylib 0x30a4e0be _objc_rootRelease + 30
3 libobjc.A.dylib 0x30a4fdb0 objc_release + 32
4 libobjc.A.dylib 0x30a4ee06 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 218
5 libobjc.A.dylib 0x30a4ed22 _objc_autoreleasePoolPop + 6
6 CoreFoundation 0x3759f050 _CFAutoreleasePoolPop + 12
7 Foundation 0x337cd460 -[NSAutoreleasePool release] + 120
8 UIKit 0x33b8d948 _UIApplicationHandleEvent + 6664
9 GraphicsServices 0x30ff8ef4 PurpleEventCallback + 876
10 CoreFoundation 0x3760a9c4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 32
11 CoreFoundation 0x3760a966 __CFRunLoopDoSource1 + 134
12 CoreFoundation 0x3760958c __CFRunLoopRun + 1364
13 CoreFoundation 0x375ab036 CFRunLoopRunSpecific + 294
14 CoreFoundation 0x375aaefe CFRunLoopRunInMode + 98
15 UIKit 0x33b8b758 -[UIApplication _run] + 544
16 UIKit 0x33b8898a UIApplicationMain + 1074
17 BoreBeta 0x00002d8a main (main.m:14)
18 BoreBeta 0x000027f8 start + 32
Thread 1 name: Dispatch queue: com.apple.libdispatch-manager
Thread 1:
0 libsystem_kernel.dylib 0x3140d214 kevent + 24
1 libdispatch.dylib 0x376aaf60 _dispatch_mgr_invoke + 708
2 libdispatch.dylib 0x376aac7e _dispatch_mgr_thread + 30
Etcetera，我相信这是唯一有用的部分。当我让它在XCode中运行崩溃时，我看到它在main中崩溃了，除了main，UIApplicationMain和CFRelease之外，我没有看到任何calltrace ..
Etcetera, i believe this is the only helpful part. When i let it crash from running in XCode, i see it crashes in main, and i don't get to see any calltrace, apart from main, UIApplicationMain and CFRelease on top..
在过去，我会通过我的代码查看过度释放的对象，但我怀疑是这种情况，因为我现在正在使用ARC。你如何修复这样的错误？
In the past, i would look through my code for overreleasing objects, but i doubt this is the case because i'm now using ARC. How do you fix errors like this?
编辑：使用GCD解析数据的代码在一个单独的线程上，这就是我唯一的@autoreleasepool所在的位置。
the code for parsing the data is on a seperate thread using GCD, and that's where my only @autoreleasepool lives.
此外，在运行NSZombieEnabled时，我正在接受NSArrayM发布调用。不幸的是，这与我们在崩溃日志中读到的相同，所以我恐怕还没有真正的进展......
Also, when running with NSZombieEnabled, i'm getting the NSArrayM release call. Unfortunately, that's the same we read in the crash log, so still no real progress here i'm afraid...
编辑：好的。一旦我在没有ARC的情况下修复了所有其他内存错误，我再次遇到此错误。所以显然它与ARC无关......
Ok. Once i fixed all my other memory errors without ARC, i got this error once again. So apparently it's not ARC-related...
推荐答案
最近引入的已知错误。
在将来的版本中修复（请注意，Xcode 4.2在NDA下，但llvm-commits不是）。提交消息为此处提供。提交消息有点模糊，但它应该涵盖您所看到的情况 - 如果在下一个编译器发布时不是这种情况（或者您可以自己构建一个，如果有这样的动机），请立即提交错误并发布bug＃here。
Fixed in a future release (Note that Xcode 4.2 is under NDA, but llvm-commits is not). The commit message is available here. The commit message is slightly vague, but it should cover the case you are seeing -- if that is not the case upon the next compiler release (or you could build one yourself, if so motivated), please immediately file a bug and post the bug # here.
这篇关于没有calltrace（使用ARC）的过度释放，主要的错误访问的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
