Now that I think about it, I suspect the log is a red herring, related only to Xcode at the time that it is preparing to report the EXC_BAD_ACCESS, and not related to the cause at all.
I know that closing an audio plug-in right after opening it is not the *normal* course of action, but it could happen, and the crash won't occur right way. (I make the URL connection right after opening the plug-in's editor window, by the way.) But it appears to me that the system is trying to release something that my delegate owned, and the delegate is no longer there. To me, this would indicate that there is a reference to the connection, or to the received data, that is not released until the system "cleans up" its idle connections. But if I'm not releasing things properly, why would the order matter so much? If the system released an object because its reference count went to 0, and then *I* released it, wouldn't it cause a crash that way, as well? I'm really stumped as to where to look. -Howard On Aug 25, 2014, at 8:15 AM, Howard Moon <how...@antarestech.com> wrote: > Hi, > > I've got an NSURLConnection owned by an NSObject that implements the > NSURLConnectionDelegate protocol, used by a C++ object inside an AudioUnits > plug-in. I'm seeing a crash occur if I close the plug-in (and thus call > dealloc on the delegate object). The crash happens about a minute (a little > less) after the asynchronous connection is initiated. If I keep my plug-in > open for at least a minute, then when I close the plug-in (or close Logic), > there is no crash. And everything else is working fine. I get my response > and send it back to a callback in my C++ object, parse the XML that I > receive, and everything looks great. It's only if I close the plug-in before > that time is up that there is a problem. > > Here is a portion of the Console output, with NSLog entries I made just to > show I'm reaching the expected delegate functions. The first listing is > where I wait a minute or so before closing the plug-in, and no problem is > seen. The second is where I close it right away (taken from the log just > after the debugger reports EXC_BAD_ACCESS). As you can see, the > didFinishLoading function has been called, so I shouldn't be expecting > anything more to be called on my delegate, should I? (Plus, I added a call > to cancel in my dealloc function, just in case!) > > Closing after at least a minute: > > Aug 25 07:55:47 server.local Logic Pro[1633]: connection started > Aug 25 07:55:48 server.local Logic Pro[1633]: received response > Aug 25 07:55:48 server.local Logic Pro[1633]: received data > Aug 25 07:55:48 server.local Logic Pro[1633]: did finish loading > Aug 25 07:57:12 server.local Logic Pro[1633]: dealloc called > > Closing right away: > > Aug 25 08:04:53 server.local Logic Pro[1741]: connection started > Aug 25 08:04:54 server.local Logic Pro[1741]: received response > Aug 25 08:04:54 server.local Logic Pro[1741]: received data > Aug 25 08:04:54 server.local Logic Pro[1741]: did finish loading > Aug 25 08:04:56 server.local Logic Pro[1741]: dealloc called > Aug 25 08:05:45 server.local filecoordinationd[128]: NSFileCoordinator only > handles URLs that use the file: scheme. This one does not: > x-xcode-disassembly://stack_frame?processID=0&threadID=3&frameID=0 > > > > Here is the relevant portion of the crash log, (if I run it outside the > debugger): > > Thread 2 Crashed:: com.apple.NSURLConnectionLoader > 0 libsystem_kernel.dylib 0x98e98a6a __pthread_kill + 10 > 1 libsystem_c.dylib 0x9342fb2f pthread_kill + 101 > 2 libsystem_c.dylib 0x93466738 __abort + 199 > 3 libsystem_c.dylib 0x93466671 abort + 232 > 4 com.apple.logic.pro 0x003e6729 std::ostream& > TraceOutContainer<CEvs>(std::ostream&, CEvs, char const*, int) + 3842985 > 5 libsystem_c.dylib 0x9341a94b _sigtramp + 43 > 6 com.apple.CoreFoundation 0x917762b5 CFRelease + 69 > 7 com.apple.CFNetwork 0x90493ab0 MixedValue::uninitialize() + > 36 > 8 com.apple.CFNetwork 0x9049ec57 MixedArray::~MixedArray() + > 59 > 9 com.apple.CFNetwork 0x9049ec0a MixedDict::~MixedDict() + 48 > 10 com.apple.CFNetwork 0x9049ebd0 > HTTPHeaderDict::~HTTPHeaderDict() + 20 > 11 com.apple.CFNetwork 0x9046fb14 CFClass::FinalizeObj(void > const*) + 28 > 12 com.apple.CoreFoundation 0x9177661a CFRelease + 938 > 13 com.apple.CFNetwork 0x90472458 HTTPMessage::~HTTPMessage() > + 118 > 14 com.apple.CFNetwork 0x9046fb14 CFClass::FinalizeObj(void > const*) + 28 > 15 com.apple.CoreFoundation 0x9177661a CFRelease + 938 > 16 com.apple.CFNetwork 0x904a050d > HTTPWriteFilter::~HTTPWriteFilter() + 79 > 17 com.apple.CFNetwork 0x9046fb14 CFClass::FinalizeObj(void > const*) + 28 > 18 com.apple.CoreFoundation 0x9177661a CFRelease + 938 > 19 com.apple.CFNetwork 0x904a0465 > NetConnection::~NetConnection() + 121 > 20 com.apple.CFNetwork 0x904a0317 > HTTPNetConnection_NoAuth::~HTTPNetConnection_NoAuth() + 17 > 21 com.apple.CFNetwork 0x904a195f > CFAllocatedReferenceCountedObject::_retainable_release(__CFAllocator const*, > void const*) + 17 > 22 com.apple.CoreFoundation 0x9177cafe __CFArrayReleaseValues + 446 > 23 com.apple.CoreFoundation 0x9177c937 __CFArrayDeallocate + 423 > 24 com.apple.CoreFoundation 0x9177661a CFRelease + 938 > 25 com.apple.CFNetwork 0x904a1655 > HTTPConnectionCacheEntry::purgeIdleConnections(double) + 281 > 26 com.apple.CFNetwork 0x904a13a3 > HTTPConnectionCache::performIdleSweep() + 245 > 27 com.apple.CFNetwork 0x904a123b > HTTPConnectionCache::timeoutIdleConnections() + 33 > 28 com.apple.CFNetwork 0x904e21b5 __block_global_0 + 20 > 29 com.apple.CFNetwork 0x90528c13 __block_global_1 + 25 > 30 com.apple.CoreFoundation 0x9179fef0 CFArrayApplyFunction + 192 > 31 com.apple.CFNetwork 0x9047e24d > RunloopBlockContext::perform() + 133 > 32 com.apple.CFNetwork 0x90528fe3 non-virtual thunk to > RunloopBlockContext::multiplexerClientPerform() + 20 > 33 com.apple.CFNetwork 0x9047e11b MultiplexerSource::perform() > + 255 > 34 com.apple.CoreFoundation 0x9177f04f > __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15 > 35 com.apple.CoreFoundation 0x9177ea79 __CFRunLoopDoSources0 + 233 > 36 com.apple.CoreFoundation 0x917a4826 __CFRunLoopRun + 934 > 37 com.apple.CoreFoundation 0x917a401a CFRunLoopRunSpecific + 378 > 38 com.apple.CoreFoundation 0x917a3e8b CFRunLoopRunInMode + 123 > 39 com.apple.Foundation 0x9871c37a +[NSURLConnection(Loader) > _resourceLoadLoop:] + 395 > 40 com.apple.Foundation 0x98780448 -[NSThread main] + 45 > 41 com.apple.Foundation 0x987803cb __NSThread__main__ + 1396 > 42 libsystem_c.dylib 0x9342e5b7 _pthread_start + 344 > 43 libsystem_c.dylib 0x93418dce thread_start + 34 > > > Any ideas what might be causing this crash? I've read a lot of stuff online > about crashes from the NSURLConnection object, and have tried to make sure > I'm following the rules, but I'm just unsure why there's that one extra entry > in the console, or what it has to do with the purging of the connection cache > entires and how that is leading to a crash. > > Thanks, > Howard > > > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/howard%40antarestech.com > > This email sent to how...@antarestech.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
