ios “线程 6 com.apple.NSURLConnectionLoader：程序收到信号：EXC_BAD_ACCESS”
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/7814917/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
"Thread 6 com.apple.NSURLConnectionLoader: Program received signal: EXC_BAD_ACCESS"
提问by iamichi
The app crashes about 15 seconds after launching and XCode just breaks at an address and gives me a pop up that says "Thread 6 com.apple.NSURLConnectionLoader: Program received signal: EXC_BAD_ACCESS"
该应用程序在启动后大约 15 秒崩溃，XCode 只是在一个地址处中断并弹出一个窗口，上面写着“线程 6 com.apple.NSURLConnectionLoader：程序收到信号：EXC_BAD_ACCESS”
I've been totally unable to track the problem down. It works fine running on iOS 4, but I'm guessing that's just because it is more tolerant of the bug or something. I've tried setting breakpoints everywhere and stepping through, running it in Instruments under the Zombies profile, but it just bombs out and doesn't tell me where. I've got not warnings and a clean analysis, so I'm at a bit of a loss where to look next. Can anyone offer any advise? Thanks.
我完全无法追踪问题。它在 iOS 4 上运行良好，但我猜这只是因为它更能容忍错误或其他东西。我试过在任何地方设置断点并逐步完成，在 Zombies 配置文件下的 Instruments 中运行它，但它只是爆炸并且没有告诉我在哪里。我没有警告和清晰的分析，所以我有点不知下一步该往哪里看。任何人都可以提供任何建议吗？谢谢。
The backtrace is:
回溯是：
(gdb) backtrace
#0 0x024fb939 in _dispatch_retain ()
#1 0x024fbc02 in dispatch_source_cancel ()
#2 0x0109e492 in _CFURLCacheDeallocate ()
#3 0x0205a4e3 in CFRelease ()
#4 0x010331b1 in HTTPProtocol::~HTTPProtocol ()
#5 0x0100c75d in CFClass::FinalizeObj ()
#6 0x0205a4e3 in CFRelease ()
#7 0x02110af0 in __CFDictionaryStandardReleaseValue ()
#8 0x020714b1 in __CFBasicHashDrain ()
#9 0x0205a4e3 in CFRelease ()
#10 0x01024237 in SocketStream::~SocketStream ()
#11 0x0100c75d in CFClass::FinalizeObj ()
#12 0x0205a4e3 in CFRelease ()
#13 0x01023e0b in SocketStream::finalize ()
#14 0x01023dc6 in virtual thunk to SocketStream::finalize(void const*) ()
#15 0x01023da1 in ReadStreamCallbacks::_finalize ()
#16 0x0208201a in __CFStreamDeallocate ()
#17 0x0205a4e3 in CFRelease ()
#18 0x01030a6c in HTTPReadFilter::~HTTPReadFilter ()
#19 0x0100c75d in CFClass::FinalizeObj ()
#20 0x0205a4e3 in CFRelease ()
#21 0x010c22bc in non-virtual thunk to HTTPReadFilter::readStreamFinalize(__CFReadStream*) ()
#22 0x0102ff1c in CFNetworkReadStream::httpStreamFinalize ()
#23 0x0208201a in __CFStreamDeallocate ()
#24 0x0205a4e3 in CFRelease ()
#25 0x0103070f in NetConnection::shutdownConnectionStreams ()
#26 0x010bf1fc in NetConnection::closeStreamsIfPossibleOrSignalThatThatNeedsToBeDonePrettyPlease ()
#27 0x0103485b in HTTPConnectionCacheEntry::removeUnauthConnection ()
#28 0x010d6d2d in HTTPConnectionCacheEntry::purgeIdleConnections ()
#29 0x010d3c1e in ConnectionCacheTLS::resetCacheForThisThread ()
#30 0x0101b739 in ConnectionTimerTLS::_timerPurgeEntries ()
#31 0x02122966 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ ()
#32 0x02122407 in __CFRunLoopDoTimer ()
#33 0x020857c0 in __CFRunLoopRun ()
#34 0x02084db4 in CFRunLoopRunSpecific ()
#35 0x02084ccb in CFRunLoopRunInMode ()
#36 0x00206e40 in +[NSURLConnection(Loader) _resourceLoadLoop:] ()
#37 0x001184e6 in -[NSThread main] ()
#38 0x00118457 in __NSThread__main__ ()
#39 0x98d6b259 in _pthread_start ()
#40 0x98d6b0de in thread_start ()
采纳答案by iamichi
The fix in the comment above didn't end up fixing it after all and it was still crashing at random times with almost no debug info.
上面评论中的修复毕竟没有最终修复它，它仍然随机崩溃，几乎没有调试信息。
With the debugger connected to my iPhone it gave a different error to the emulator and I saw a reference to a NSURLCache object. I then remembered I had some old code left over from trying to fix a memory leak in the NSURLConnection object...
将调试器连接到我的 iPhone 后，它给模拟器带来了不同的错误，我看到了对 NSURLCache 对象的引用。然后我想起我在尝试修复 NSURLConnection 对象中的内存泄漏时遗留了一些旧代码......
NSURLCache *sharedCache = [[NSURLCache alloc] initWithMemoryCapacity:0 diskCapacity:0 diskPath:nil];
[NSURLCache setSharedURLCache:sharedCache];
[sharedCache release];
and also in another class I had...
在另一堂课上，我...
[[NSURLCache sharedURLCache] setMemoryCapacity:0];
[[NSURLCache sharedURLCache] setDiskCapacity:0];
Removing these fixed the problem and also explained to me why it was so hard to track down. This looks to me like a bug somewhere in Apple's code as it was a total pain to track down with almost no error messages.
删除这些解决了问题，并向我解释了为什么很难追踪。在我看来，这就像 Apple 代码中某个地方的错误，因为在几乎没有错误消息的情况下进行追踪非常痛苦。
I hope that helps someone else.
我希望能帮助别人。
回答by chown
Set NSZombieEnabled, MallocStackLogging, and guard mallocin the debugger. Then, when your App crashes, type this in the gdb console:
在调试器中设置NSZombieEnabled、MallocStackLogging和保护 malloc。然后，当您的应用程序崩溃时，在 gdb 控制台中输入：
(gdb) info malloc-history 0x543216
Replace 0x543216with the address of the object that caused the crash, and you will get a much more useful stack trace and it should help you pinpoint the exact line in your code that is causing the problem.
替换0x543216为导致崩溃的对象的地址，您将获得更有用的堆栈跟踪，它应该可以帮助您查明代码中导致问题的确切行。
回答by Jeremy
Thanks iamichi for your efforts in tracking down this bug. This fixed my issue.
感谢 iamichi 为追踪此错误所做的努力。这解决了我的问题。
One thing to note:
需要注意的一件事：
I removed the following code from my app just as you did:
我和你一样从我的应用程序中删除了以下代码：
NSURLCache *sharedCache = [[NSURLCache alloc] initWithMemoryCapacity:0 diskCapacity:0 diskPath:nil];
[NSURLCache setSharedURLCache:sharedCache];
[sharedCache release];
and placed the following code (didn't remove) in the application delegate:
并在应用程序委托中放置以下代码（未删除）：
[[NSURLCache sharedURLCache] setMemoryCapacity:0];
[[NSURLCache sharedURLCache] setDiskCapacity:0];
All is well. Thanks!
一切都很好。谢谢！
