Re: Crash from NSURLConnection if delegate released too soon?
I’m not entirely sure this crash is down to you nor that it’s calling any methods on your correctly deallocated instance of NSURLConnection or the delegate. To me it looks like the HTTP cache subsystem is purging data and tripping over itself because of something it cleaned up when the NSURLConnection was closed earlier, perhaps a weak NSURL pointer it had to a temporary file which it nil’ed or similar, or a bug in the HTTP cache system when plugins using it are unloaded which yanks out data it’s going to access later. Do you still get the crash if you change your cache policy? Not that you necessarily can change it for your app, just a question of trying to narrow down where the error is coming from. You could also perhaps implement some of the URL cacheing callbacks on the delegate to try and circumvent the OS trying to store data, not sure that has too much mileage in it. This starts to look to me more like a framework bug than your own. I do believe you're right that it's not my bug. GarageBand also crashes if I remove my plug-in before the system cleans up idle connections, as does Cubase, using my VST3 build. And the stack trace at crash time doesn't enter into my code (which makes sense, since my classes have all been destroyed already). But if I leave the plug-in open until those connections are cleaned up, then there is no problem. Not good, but not sure if there's anything I can do at this point. 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Crash from NSURLConnection if delegate released too soon?
> On 26 Aug 2014, at 12:40 am, Howard Moon wrote: > > 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 That didn’t sound quite right, either way Jens followed up with some rules which did sound right. I’m not entirely sure this crash is down to you nor that it’s calling any methods on your correctly deallocated instance of NSURLConnection or the delegate. To me it looks like the HTTP cache subsystem is purging data and tripping over itself because of something it cleaned up when the NSURLConnection was closed earlier, perhaps a weak NSURL pointer it had to a temporary file which it nil’ed or similar, or a bug in the HTTP cache system when plugins using it are unloaded which yanks out data it’s going to access later. Do you still get the crash if you change your cache policy? Not that you necessarily can change it for your app, just a question of trying to narrow down where the error is coming from. You could also perhaps implement some of the URL cacheing callbacks on the delegate to try and circumvent the OS trying to store data, not sure that has too much mileage in it. This starts to look to me more like a framework bug than your own. ___ 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
Re: Crash from NSURLConnection if delegate released too soon?
On Aug 25, 2014, at 2:13 PM, Jens Alfke wrote: > >> On Aug 25, 2014, at 1:43 PM, Howard Moon wrote: >> >> The Apple docs show simply setting the connection and receivedData to nil, >> instead of calling release on them. > > Do you have a strong [sic] reason to be using manual retain/release? If not, > I'd _really_ recommend switching to ARC, at least for this one source file, > especially since it sounds like you don't have the memory-management rules > firmly memorized yet. > I've never used or looked into ARC at all. I'm on a tight deadline, so switching to a new way of doing things might not be advisable at this point. I'm guessing that the setting to nil in the newest Apple docs *assumes* I'm using ARC, then? They might mention that somewhere. I'm pretty sure I only release those things that I alloc (or copy). I don't have any problems with other Cocoa classes I'm using. The only issue seems to be this NSURLConnection object. And what's been confusing me is apparently this mixing of examples using ARC and not. > Have you run the static analyzer (Cmd-Shift-B)? It's good at finding and > explaining ref-counting mistakes. > Yes, and it shows a "potential leak" for theConnection if I don't call release on it explicitly in the launching function, even though it is released in the completion and error functions. Nothing else is noted in this file (or any related files). > Have you tried using NSZombie? That's a good way to track down over-released > objects at runtime. (See Technical Note TN2239, iOS Debugging Magic.) > Not yet. (I'm writing desktop software, by the way, not iOS stuff.) > —Jens ___ 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
Re: Crash from NSURLConnection if delegate released too soon?
> On Aug 25, 2014, at 1:43 PM, Howard Moon wrote: > > The Apple docs show simply setting the connection and receivedData to nil, > instead of calling release on them. Do you have a strong [sic] reason to be using manual retain/release? If not, I'd _really_ recommend switching to ARC, at least for this one source file, especially since it sounds like you don't have the memory-management rules firmly memorized yet. Have you run the static analyzer (Cmd-Shift-B)? It's good at finding and explaining ref-counting mistakes. Have you tried using NSZombie? That's a good way to track down over-released objects at runtime. (See Technical Note TN2239, iOS Debugging Magic.) —Jens ___ 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
Re: Crash from NSURLConnection if delegate released too soon?
Damn. That didn't fix it. Several tests since then have seen it happen again. I changed the connection to use this request, but it didn't change anything: NSMutableURLRequest *postRequest = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"https://transactions.antarestech.com/securevocal/ProductVersionProvider.aspx";] cachePolicy:NSURLRequestReloadIgnoringLocalAndRemoteCacheData timeoutInterval:10.0]; I don't see what the problem is. I've tried it exactly like the Apple reference documents show, and I've got it slightly changed from that, as shown here: http://cagt.bu.edu/w/images/8/8b/URL_Connection_example.txt but no luck either way. The Apple docs show simply setting the connection and receivedData to nil, instead of calling release on them. The docs don't show the declaration of dataReceived (or if there is a @property in the .h and @syntheize in the .m (or .mm) file), as the cagt example does. The cagt example also shows retaining dataReceived if the connection is created: self.receivedData = [[NSMutableData data] retain]; This would be why it's released in those functions instead of simply set to nil as the Apple docs show. But I've tried it both ways, and no difference. I've also tried releasing the connection itself immediately after creation, as some online posts have stated. This does not help, either. I do notice one error in the Apple docs: they show "theConnection" as a local variable declared in the function where the connection is created, but then release "theConnection" in both connectionDidFinishLoading and didFailWithError, even though the parameter for both of those functions is declared as "connection", not "theConnection". This means that their code will not compile (and is what initially led me to declare theConnection as a member of my delegate class). If it won't even compile, it's no surprise it doesn't work as expected, either. Is there an example of code out there that actually *works*? I'm doing a one-time POST upon opening my plug-in's editor window (assuming it has not already been done by this instance or by another instance of the plug-in). It should be simple enough to just follow the guidelines and Apple's example, but I've spent a few days trying to get this stupid thing to work! Thanks, Howard On Aug 25, 2014, at 9:54 AM, Jens Alfke wrote: > >> On Aug 25, 2014, at 9:40 AM, Howard Moon wrote: >> >> 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. > > It should be OK either way as long as you're following the ref-counting rules > (or are using ARC.) > * Only release the NSURLConnection if you allocated it by calling +alloc > * Don't release the NSURLConnection instance passed into your delegate methods > > Also, NSURLConnection instances always stay alive until the connection > finishes (they are retained by CFNetwork internally) so you actually don't > need to retain them yourself. > > —Jens ___ 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
Re: Crash from NSURLConnection if delegate released too soon?
> On Aug 25, 2014, at 9:40 AM, Howard Moon wrote: > > 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. It should be OK either way as long as you're following the ref-counting rules (or are using ARC.) * Only release the NSURLConnection if you allocated it by calling +alloc * Don't release the NSURLConnection instance passed into your delegate methods Also, NSURLConnection instances always stay alive until the connection finishes (they are retained by CFNetwork internally) so you actually don't need to retain them yourself. —Jens ___ 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
Re: Crash from NSURLConnection if delegate released too soon?
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 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 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.dylib0x9342fb2f pthread_kill + 101 >> 2 libsystem_c.dylib0x93466738 __abort + 199 >> 3 libsystem_c.dylib0x93466671 abort + 232 >> 4 com.apple.logic.pro 0x003e6729 std::ostream& >> TraceOutContainer(std::ostream&, CEvs, char const*, int) + 3842985 >> 5 libsystem_c.dylib0x9341a94b _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
Re: Crash from NSURLConnection if delegate released too soon?
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 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.dylib0x98e98a6a __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(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.CoreFoundatio
Crash from NSURLConnection if delegate released too soon?
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(std::ostream&, CEvs, char const*, int) + 3842985 5 libsystem_c.dylib 0x9341a94b _sigtramp + 43 6 com.apple.CoreFoundation0x917762b5 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.CoreFoundation0x9177661a CFRelease + 938 13 com.apple.CFNetwork 0x90472458 HTTPMessage::~HTTPMessage() + 118 14 com.apple.CFNetwork 0x9046fb14 CFClass::FinalizeObj(void const*) + 28 15 com.apple.CoreFoundation0x9177661a CFRelease + 938 16 com.apple.CFNetwork 0x904a050d HTTPWriteFilter::~HTTPWriteFilter() + 79 17 com.apple.CFNetwork 0x9046fb14 CFClass::FinalizeObj(void const*) + 28 18 com.apple.CoreFoundation0x9177661a 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.CoreFoundation0x9177cafe __CFArrayReleaseValues + 446 23 com.apple.CoreFoundation0x9177c937 __CFArrayDeallocate + 423 24 com.apple.CoreFoundation0x9177661a 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.CoreFoundation0x9179fef0 CFArrayApplyFunction + 192 31 com.apple.CFNetwork
