Ok, I fixed it. I was using the connection object as a member of my class, and
releasing that, when I should have been releasing the connection that is given
to me inside didFailWithError and connectionDidFinishLoading, not making it a
member at all.
Regards,
Howard
On Aug 25, 2014, at 8:51 AM, Howard Moon <how...@antarestech.com> wrote:
> 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/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
