User Profile

I was able to create a reliable reproducer of the precondition failure. The magic combination seems to be a SwiftUI List in a Tab, where each element in the List utilizes a GeometryReader to read the GeometryProxy's frame. Also, the List rows are populated in "onAppear". Simply switching to a tab containing a List configured as described causes the precondition failure.I've submitted FB7733658.

We're seeing a _very_ similar crash. Though it doesn't reproduce 100% of the time, it happens quite regularly.Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Application Specific Information: abort() called CoreSimulator 704.12.2 - Device: iPhone 11 (2CFE4E5E-4E50-4F44-A315-7E722C65F4AC) - Runtime: iOS 13.5 (17F61) - DeviceType: iPhone 11 AttributeGraph precondition failure: invalid input index: 2. Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff51b617fa __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007fff51c0cbc1 pthread_kill + 432 2 libsystem_c.dylib 0x00007fff51af0b7c abort + 120 3 com.apple.AttributeGraph 0x00007fff2fc8ce40 AG::precondition_failure(char const*, ...) + 273 4 com.apple.AttributeGraph 0x00007fff2fc64846 AG::Graph::input_value_ref_slow(unsigned int, unsigned int, AGTypeID, bool*) + 490 5 com.apple.SwiftUI 0x00007fff2c538ab1 RootGeometry.update(context:) + 97 6 com.apple.SwiftUI 0x00007fff2c53c4d8 partial apply for protocol witness for static UntypedAttribute._update(_:graph:attribute:) in conformance RootGeometry + 24 7 com.apple.AttributeGraph 0x00007fff2fc60d3d AG::Graph::UpdateStack::update() + 455 8 com.apple.AttributeGraph 0x00007fff2fc6124b AG::Graph::update_attribute(unsigned int, bool) + 373 9 com.apple.AttributeGraph 0x00007fff2fc64723 AG::Graph::input_value_ref_slow(unsigned int, unsigned int, AGTypeID, bool*) + 199 10 com.apple.SwiftUI 0x00007fff2c5ceb92 _PositionAwareLayoutContext.dimensions.getter + 50 11 com.apple.SwiftUI 0x00007fff2c65c164 partial apply for thunk for @callee_guaranteed () -> (@unowned CGSize) + 20 12 com.apple.SwiftUI 0x00007fff2c65c582 specialized closure #1 in GeometryProxy.sync<A>(_:) + 66 13 com.apple.SwiftUI 0x00007fff2c65ca7e specialized closure #1 in GeometryProxy.sync<A>(_:) + 14 14 com.apple.SwiftUI 0x00007fff2c65caa1 partial apply for specialized + 17 15 com.apple.SwiftUI 0x00007fff2c80ee27 ViewRendererHost.updateViewGraph<A>(body:) + 71 16 com.apple.SwiftUI 0x00007fff2c80eb23 protocol witness for ViewGraphDelegate.updateViewGraph<A>(body:) in conformance _UIHostingView<A1> + 19 17 com.apple.SwiftUI 0x00007fff2c65b5ca GeometryProxy.size.getter + 186 18 com.apple.SwiftUI 0x00007fff2c65c3e5 GeometryProxy.frame(in:) + 21 19 com.myco.UI 0x0000000103bfe695 closure #1 in FramePreferenceViewModifier.body(content:) + 149 (FramePreference.swift:54) 20 com.myco.UI 0x0000000103bffb3c partial apply for closure #1 in FramePreferenceViewModifier.body(content:) + 12 21 com.apple.SwiftUI 0x00007fff2c65be76 GeometryReader.Child.update(context:) + 390 22 com.apple.SwiftUI 0x00007fff2c65c0b0 protocol witness for static UntypedAttribute._update(_:graph:attribute:) in conformance GeometryReader<A>.Child + 32 23 com.apple.AttributeGraph 0x00007fff2fc78309 partial apply + 25 24 com.apple.AttributeGraph 0x00007fff2fc60d3d AG::Graph::UpdateStack::update() + 455 25 com.apple.AttributeGraph 0x00007fff2fc6124b AG::Graph::update_attribute(unsigned int, bool) + 373 26 com.apple.AttributeGraph 0x00007fff2fc65d53 AG::Subgraph::update(unsigned int) + 729 27 com.apple.SwiftUI 0x00007fff2c5359e0 ViewGraph.runTransaction(in:) + 224 28 com.apple.SwiftUI 0x00007fff2c535796 closure #1 in ViewGraph.flushTransactions() + 262 29 com.apple.SwiftUI 0x00007fff2c535475 ViewGraph.flushTransactions() + 213 30 com.apple.SwiftUI 0x00007fff2c819ac3 closure #1 in ViewRendererHost.render(interval:updateDisplayList:) + 179 31 com.apple.SwiftUI 0x00007fff2c80f785 ViewRendererHost.render(interval:updateDisplayList:) + 373 32 com.apple.SwiftUI 0x00007fff2c96f9e2 _UIHostingView.layoutSubviews() + 226 33 com.apple.SwiftUI 0x00007fff2c96fa05 @objc _UIHostingView.layoutSubviews() + 21 34 com.apple.UIKitCore 0x00007fff49193678 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 2478 35 com.apple.QuartzCore 0x00007fff2b4c6398 -[CALayer layoutSublayers] + 255 36 com.apple.QuartzCore 0x00007fff2b4cc523 CA::Layer::layout_if_needed(CA::Transaction*) + 523 37 com.apple.QuartzCore 0x00007fff2b4d7bba CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 80 38 com.apple.QuartzCore 0x00007fff2b420c04 CA::Context::commit_transaction(CA::Transaction*, double) + 324 39 com.apple.QuartzCore 0x00007fff2b4545ef CA::Transaction::commit() + 649 40 com.apple.SwiftUI 0x00007fff2c96fb14 _UIHostingView.displayLinkTimer(timestamp:) + 244 41 com.apple.SwiftUI 0x00007fff2c45343d DisplayLink.displayLinkTimer(_:) + 77 42 com.apple.SwiftUI 0x00007fff2c453496 @objc DisplayLink.displayLinkTimer(_:) + 38 43 com.apple.QuartzCore 0x00007fff2b3814c6 CA::Display::DisplayLink::dispatch_items(unsigned long long, unsigned long long, unsigned long long) + 538 44 com.apple.QuartzCore 0x00007fff2b4588f0 display_timer_callback(__CFMachPort*, void*, long, void*) + 299 45 com.apple.CoreFoundation 0x00007fff23d6187d __CFMachPortPerform + 157 46 com.apple.CoreFoundation 0x00007fff23da14e9 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 41 47 com.apple.CoreFoundation 0x00007fff23da0ae8 __CFRunLoopDoSource1 + 472 48 com.apple.CoreFoundation 0x00007fff23d9b514 __CFRunLoopRun + 2228 49 com.apple.CoreFoundation 0x00007fff23d9a944 CFRunLoopRunSpecific + 404 50 com.apple.GraphicsServices 0x00007fff38ba6c1a GSEventRunModal + 139 51 com.apple.UIKitCore 0x00007fff48c8b9ec UIApplicationMain + 1605 52 com.myco.myapp 0x0000000100821e28 main + 56 (AppDelegate.swift:14) 53 libdyld.dylib 0x00007fff51a231fd start + 1

"Stream.getStreamsToHost()" does prevent us from getting blocked. The updated sample application associated with the Radar is set up to demonstrate that.That said, we've tested eliminating the call to "URLSessionStreamTask.captureStreams()" by using its "readData(:Int,:Int,:TimeInterval:(Data?,Bool,Error?)->Void)" and "writeData(:Data,:TimeInterval,:(Error?)->Void)" methods directly. Our code is significantly simplified. Unit tests however, have broken in an unfortunate way - it's harder to mock URLSessionStreamTask than it was to mock a Stream.At this point, we're going to continue to plow forward using "URLSessionStreamTask.readData(...)" and "URLSessionStreamTask.writeData(...)" for future releases of our app. They eliminate the need to call URLSessionStreamTask.captureStreams() and prevent us from touching the underlying Stream objects altogether. Given the typical cadence of iOS releases, we anticipate having enough time to get a new build through our QA and onto the store by the time iOS 11 is released. Knowing our customer base though, I would anticipate that our help desk will get a number of calls from folks that have upgraded to iOS 11, but not upgraded our app. Thus, if the CFNetwork team can fix the regression prior to the official release of iOS 11, it would be appreciated. We'd be happy to test any fixes in a very timely manner.

Quinn,Thanks so much for responding and confirming that this is a regression.We switched over to using NSURLSession in 2015 after viewing the latter segment of WWDC 2015's “Networking with NSURLSession” (Session 711). We did so for several reasons:Dealing with SSL and proxies was a historical pain point. SSL for us (getting it configured properly) and proxies for our users (as users encountered new proxies, we’d get support calls regarding connectivity). NSURLSession promised to take care of that for us and has done so since we began using it.We could use NSURLSession to obtain streams as we had historically done without major disruption to our existing algorithm.We send a standard HTTP GET request when we initially open the connection to inform an F5 which server resource we’re contacting. NSURLSession makes this quite easy.Using “Stream.getStreamsToHost(…)” does work, but we lose the benefits of the items above.I altered the sample application provided with the radar to avoid using “hasBytesAvailable”. I’ll attach the updated sample application to the radar. The thread still blocks. The crux of the issue is this:the stream has 59 bytes availablewe call “inputStream.read(&buffer, maxLength: 4)”we receive 4 bytes and interpret those bytes as a 32bit Int (whose value is 55).we call “inputStream.read(&buffer, maxLength: 55)”the thread blocksIt appears to us as if reading less than the available bytes, followed by reading the remaining available bytes will cause the thread to block. Is that expected?This is the stack trace when the thread blocks at step 5:Thread 5 Queue : Anonymous#0 0x0000000113e3a31e in __ulock_wait ()#1 0x0000000113e5faff in _os_ulock_wait ()#2 0x0000000113e5f7d0 in _os_nospin_lock_lock_slow ()#3 0x000000010f643bef in __NSCFTCPIOReadStream::_streamImpl_Read(__CFReadStream*, unsigned char*, long, CFStreamError*, unsigned char*) ()#4 0x000000010fc4b54c in CFReadStreamRead ()#5 0x000000010e628ee9 in static FourByteHeaderMessageProcessor.readFromInputStream(_:atMost:) at /...Sanitized.../StreamFailure/ClientCommon/FourByteHeaderMessageProcessor.swift:43#6 0x000000010e629d23 in FourByteHeaderMessageProcessor.readBytesWith4ByteHeader(timeoutTimeInterval:maxMessageLength:) at /...Sanitized.../StreamFailure/ClientCommon/FourByteHeaderMessageProcessor.swift:88#7 0x000000010e621b3a in closure #1 in static URLSessionStreamTaskManager._urlSessionRead() at /...Sanitized.../StreamFailure/ClientCommon/URLSessionStreamTaskManager.swift:74#8 0x000000010e625075 in URLSessionStreamTaskManager.urlSession(_:streamTask:didBecome:outputStream:) at /...Sanitized.../StreamFailure/ClientCommon/URLSessionStreamTaskManager.swift:208#9 0x000000010e6256db in @objc URLSessionStreamTaskManager.urlSession(_:streamTask:didBecome:outputStream:) ()#10 0x000000010f6ce97e in __88-[NSURLSession delegate_streamTask:didBecomeInputStream:outputStream:completionHandler:]_block_invoke ()#11 0x000000010e9689b7 in __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ ()#12 0x000000010e96881a in -[NSBlockOperation main] ()#13 0x000000010e966cd6 in -[__NSOperationInternal _start:] ()#14 0x00000001139ab43c in _dispatch_client_callout ()#15 0x00000001139b0af4 in _dispatch_block_invoke_direct ()#16 0x00000001139ab43c in _dispatch_client_callout ()#17 0x00000001139b0af4 in _dispatch_block_invoke_direct ()#18 0x00000001139b0884 in dispatch_block_perform ()#19 0x000000010e962ce4 in __NSOQSchedule_f ()#20 0x00000001139ab43c in _dispatch_client_callout ()#21 0x00000001139b1856 in _dispatch_continuation_pop ()#22 0x00000001139afc86 in _dispatch_async_redirect_invoke ()#23 0x00000001139b71f9 in _dispatch_root_queue_drain ()#24 0x00000001139b6e97 in _dispatch_worker_thread3 ()#25 0x0000000113e6e5a2 in _pthread_wqthread ()#26 0x0000000113e6e07d in start_wqthread ()