On 2010 Apr 19, at 21:55, Jeff Johnson wrote: > I don't know about the FTP crash, but I believe that the other two crashes > are due to a 10.6.3 regression. I've filed <rdar://problem/7816615>....
I can definitely reproduce Jeff's crashes, and tried to isolate factors and relate to my apps, but this is a real bugger. In case anyone else finds themself "crashing" into the NSURLConnection Mac OS 10.6.3 Community, after you've tried Jeff's demos mentioned in the previous post, here's some more: My Demo Project: http://sheepsystems.com/engineering/NSURLConnectionCrash2010.zip Apple Problem ID: 7893849 Title: NSURLConnection Crashes : Mac OS 10.6.3 Edition! Summary: Back in 2005 there were several reports in cocoa-dev@lists.apple.com of NSURLConnection crashing in Mac OS X 10.4. For example see my Problem ID 4347324. Crashes occur when many NSURLConnections are open. Similar problems seem to have returned in Mac OS X 10.6.3. See Jeff Johnson's Problem ID 7816615. I spent most of yesterday in Apple's Cupertino lab trying to further refine Jeff's result and also see how it was related to crash reports I had received from two users of my applications. Unfortunately, I didn't get very far. Jeff and I may in fact be dealing with separate issues. Jeff's demo apps [1] open 194 connections simultaneously. Granted: That's not a good idea to do in real life. But my apps, with which my two users reported crashes, limit themselves to 16 open connections. The demo app which I have attached to this project allows the user to set the limit. Jeff's demo app gets 97 URLs by screen-scraping a "videos" web page of a member of the U.S. House of Representatives, and opening two connections for each of them. Attempting better control, my demo app reads these 97 URLs, plus the ~1200 URLs I received from my two users, from a file. One reason I say I didn't get very far is that even with this control I was unable to isolate the factors which cause the trouble or even reproduce the crashes. Using the URL arrays provided by my users, and using the same type of Macs at the lab, I was unable to reproduce the crashes (20 runs, 0 crashes). The users report crashing more often than not. One possible difference is the type of internet connection. I presume that my users have cable or DSL "broadband" service which is subject to traffic shaping as explained in "Environment", below. No such traffic shaping is apparent in the Cupertino lab. Another reason I didn't get very far is that the only factor I was able to isolate was using the Instruments' Threads performance tool. This definitely causes the app to crash. More logging (NSLog) also seems to be inhibit crashes. Possibly Jeff's demo apps crash more consistently because they do very little logging. I hope to do some more work on this, but am submitting now in hopes that it may stimulate some action at Apple. Hoping for 10.6.4 :)) [1] Jeff has actually made two demo apps. The demo app submitted with Problem ID 7816615 uses the asynchronous NSURLConnection methods. The code given in the third post by 'lapcat' in this thread: https://rentzsch.lighthouseapp.com/projects/24342/tickets/615-crash-at-httpwwwpingreehousegovlegisappropriations uses the synchronous method -[NSString stringWithContentsOfURL:usedEncoding:error:] in threads created by -[[NSThread detachNewThreadSelector:toTarget]. The demo app I've attached to this problem allows the user to select either. Steps to Reproduce: Environment. The following results are reproducible on my Early 2006 Intel Core Duo Mac Mini, Mac OS X 10.6.3, Earthlink residential DSL service. I mention the latter because Earthlink residential DSL service obviously applies a traffic-shaping policy, which is to drop all packets for a minute or so, after a minute or so of rapidly visiting different servers. This Earthlink policy may be a factor in obtaining the results, just as Instruments' Threads tool. 1. Open in Xcode 3.2.1 2. Run > Run with Performance Tool > Threads 3. When window opens, leave default settings (Threaded, 16, loggingLevel=0) 4. Click "Start Test" 5. Watch progress in Console.app. Expected Result: No crash Actual Result: About 80% of the time, after a few seconds, one of the secondary threads will crash with a call stack very similar to that you get when running Jeff Johnson's demo app in Problem ID 7816615. See EXAMPLE CRASH below. If it does not crash, let it run for 70 seconds or so, until "All NSURLConnection Threads have completed" logs to console. (Laggard connections will time out after 60 seconds.) Then "Start Test" again. However, I've found that if it doesn't crash in the first few seconds after beginning the first test after application launch, it's not going to crash. Subsequent "Start Test" runs in the same application launch never crash. Variation: If instead of Run > Run with Performance Tool > Threads you click Build > Build and Debug - Breakpoints On or Breakpoints Off then it won't crash EXAMPLE CRASH: Thread 11 Crashed: 0 com.apple.CoreFoundation 0x00301d04 CFRelease + 196 1 com.apple.CFNetwork 0x03f368ec HTTPProtocol::destroyReadStream() + 184 2 com.apple.CFNetwork 0x03f367b1 HTTPProtocol::cleanupStreams() + 93 3 com.apple.CFNetwork 0x03f36acb HTTPProtocol::~HTTPProtocol() + 155 4 com.apple.CoreFoundation 0x00301ea1 _CFRelease + 353 5 com.apple.CFNetwork 0x03f3654c URLConnectionLoader::reallyCleanUpProtocol(unsigned char) + 240 6 com.apple.CFNetwork 0x03f91249 URLConnectionLoader::cleanupProtocolFromClientThread() + 25 7 com.apple.CFNetwork 0x03f0c2c8 URLConnectionClient::getRequestForTransmission(_CFURLResponse*, _CFURLRequest const*, __CFError**) + 574 8 com.apple.CFNetwork 0x03f0bcaf URLConnectionClient::_clientWillSendRequest(_CFURLRequest const*, _CFURLResponse*, URLConnectionClient::ClientConnectionEventQueue*) + 223 9 com.apple.CFNetwork 0x03f9054a URLConnectionClient::ClientConnectionEventQueue::processAllEventsAndConsumePayload(XConnectionEventInfo<XClientEvent, XClientEventParams>*, long) + 148 10 com.apple.CFNetwork 0x03f0bace URLConnectionClient::processEvents() + 94 11 com.apple.CFNetwork 0x03f0b96f MultiplexerSource::perform() + 183 12 com.apple.CoreFoundation 0x0033415b __CFRunLoopDoSources0 + 1563 13 com.apple.CoreFoundation 0x00331c1f __CFRunLoopRun + 1071 14 com.apple.CoreFoundation 0x003310f4 CFRunLoopRunSpecific + 452 15 com.apple.CoreFoundation 0x00330f21 CFRunLoopRunInMode + 97 16 com.apple.CFNetwork 0x03f56f81 CFURLConnectionSendSynchronousRequest + 419 17 com.apple.Foundation 0x0146276f +[NSURLConnection sendSynchronousRequest:returningResponse:error:] + 142 18 com.apple.Foundation 0x01452ffb -[NSString initWithContentsOfURL:usedEncoding:error:] + 254 19 com.apple.Foundation 0x014520d5 +[NSString stringWithContentsOfURL:usedEncoding:error:] + 95 20 com.yourcompany.NSURLCC2010 0x00002c65 -[NC2010AppDelegate loadUrlString:] + 189 (NC2010AppDelegate.m:159) 21 com.apple.Foundation 0x012f48dc -[NSThread main] + 45 22 com.apple.Foundation 0x012f488c __NSThread__main__ + 1499 23 libSystem.B.dylib 0x0003da19 _pthread_start + 345 24 libSystem.B.dylib 0x0003d89e thread_start + 34 _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
