Post not yet marked as solved
It appears the preview titlebar rendering may be incorrect / buggy.
As a test, I put a rectangle in the inspector and it is consistent with the runtime behavior of filling only the under-titlebar area.
It just seems like the preview is incorrectly rendering the titlebar as full-height, but the preview is not actually a full-height inspector.
struct ContentView: View {
var body: some View {
VStack {
Image(systemName: "globe")
.imageScale(.large)
.foregroundStyle(.tint)
Text("Hello, world!")
}
.padding()
.toolbar {
Text("test")
}
.inspector(isPresented: .constant(true)) {
Rectangle().fill(.red)
}
}
}
Preview:
Runtime:
Post not yet marked as solved
I can reproduce this. Issue only occurs on-device with iOS 17 beta 6. Works fine in a simulator.
I believe it's an internal bug in AVAssetExportSession. I've submitted a radar to Apple (FB12986599) with detailed info and an example Xcode project to reproduce the issue.
Post not yet marked as solved
Same issue here. After trying everyone's suggestions from this thread and coming up dry, I finally narrowed down the needle-in-a-haystack.
In my case it was a Swift Package. Debug builds built fine, but Release builds (with optimizations) caused the Swift compiler to crash with the same stack trace and error: Abort trap: 6 as others have mentioned.
The culprit? A single missing import statement in one of the package's .swift files.
To elaborate the particulars:
PackageA (crashed compiler) has PackageB as a dependency, which in turn has PackageC as a dependency.
All three packages show up in the dependency pool of course.
PackageA was accessing methods from PackageC without actually using an import PackageC statement (possibly by way of PackageB exporting types from PackageC in some of its interfaces).
The missing import statement was forgotten because compilation succeeded in Debug builds and development and testing was only ever done in a Debug build. It wasn't until production Release builds of an application that imported PackageA that the compiler crash mysteriously cropped up with very little context.
From the swift.org forums, this solution was presented:
Inside of PackageA, replace all
import PackageB
with
@_implementationOnly import PackageB
There may be some side-effects, but so far it has worked exactly as desired in several different scenarios.
> how was NWProtocolIP.Metadata() integrated with UDPClient?Sorry, I realized that wasn't fully explained. I have updated my answer above with more detail.> the stateUpdateHandler should provide insight into the state of the connection. Is there anything more that you can share in self?.stateDidChange(to: state) to get a better sense here also?No actually, it's simply a method that prints the result of the state to the console. It only gets called once, at the first instantiation of my UDPClient class and enters the 'ready' state. It never changes from 'ready' state but that's likely by design and isn't an issue. After solving my problem, the NWConnection has no trouble resuming data transmission when network connectivity is restored. My theory is that NWConnection when set to .udp parameters has no need/purpose to change state?
Looks like I may have answered my own question.I was instancing my UDPClient class like this:let metadata = NWProtocolIP.Metadata()
metadata.serviceClass = .responsiveData
let context = NWConnection.ContentContext(identifier: "OSC", metadata: [metadata])
udpClient = UDPClient(name: "udpclient", host: host, port: port, context: context)By process of trial-and-error, the resolution was to remove the first 3 lines and just let Network Framework use default packet context in my constructor:udpClient = UDPClient(name: "udpclient", host: host, port: port)In hindsight, I think grabbing metadata from NWProtocolIP and using it for UDP was causing Network Framework to trip over itself and it wasn't obvious I had made that mistake. If anything, it should have been NWProtocolUDP.Metadata() but UDP metadata has no properties so there's no point even using it.The only reason I was defining custom context/metadata was in hopes of elevating packet priority in the network (which is what .responsiveData plays a role in), however that is not available on UDP.
