Post

Replies

Boosts

Views

Activity

Canvas view crashing with Core Graphics-based drawing
One of my SwiftUI applications using a Canvas view started to crash with Xcode 16. It was working flawlessly with Xcode 15. I was able to come up with a minimal SwiftUI app that shows the issue: @main struct CanvasTest: App { var body: some Scene { WindowGroup { VStack { Canvas { context, size in context.withCGContext { cgContext in let z = Int(size.width / 3.0) for i in 0..<18000 { // crashes from 17413 on cgContext.beginPath() cgContext.move(to: CGPoint(x: (i % z) * 3, y: (i / z) * 2)) cgContext.addLine(to: CGPoint(x: (i % z) * 3 + 2, y: (i / z) * 2)) cgContext.strokePath() } } } } } } } The canvas displays 18000 lines and the context.withCGContext invocation also completes successfully. Yet, the application crashes immediately after like this (details below): Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000001, 0x00000001800eabb4 Termination Reason: SIGNAL 5 Trace/BPT trap: 5 Terminating Process: exc handler [2162] I was wondering if anyone else noticed that change and found a way to fix it? Alternatively, I am looking for workarounds. I have to be able to display large drawings created via core context-based graphics. Is this worth reporting to Apple? Thanks already now for any help and advice. Hardware Model: Mac15,9 Process: CanvasTest [2162] Path: /Users/USER/Library/Developer/CoreSimulator/Devices/0C372C7C-3D00-48AA-8124-799CB9A35C1E/data/Containers/Bundle/Application/EBAEC7A2-C93D-48B7-9754-4F3F54A33084/CanvasTest.app/CanvasTest Identifier: com.objecthub.CanvasTest Version: 1.0 (1) Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd_sim [98324] Coalition: com.apple.CoreSimulator.SimDevice.0C372C7C-3D00-48AA-8124-799CB9A35C1E [58431] Responsible Process: SimulatorTrampoline [3499] Date/Time: 2024-12-01 14:33:07.7617 +0100 Launch Time: 2024-12-01 14:33:07.4151 +0100 OS Version: macOS 15.1.1 (24B91) Release Type: User Report Version: 104 Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000001, 0x00000001800eabb4 Termination Reason: SIGNAL 5 Trace/BPT trap: 5 Terminating Process: exc handler [2162] Triggered by Thread: 0 Application Specific Information: Abort Cause 268435470 Thread 0 Crashed:: Dispatch queue: com.Metal.CommandQueueDispatch 0 libxpc.dylib 0x1800eabb4 _xpc_connection_release_message.cold.1 + 60 1 libxpc.dylib 0x1800c9910 _xpc_connection_release_message + 240 2 libxpc.dylib 0x1800c80b4 _xpc_connection_enqueue + 264 3 libxpc.dylib 0x1800c8b9c xpc_connection_send_message + 128 4 MTLSimDriver 0x2275c6e7c -[MTLSimCommandQueue submitCommandBuffers:count:] + 368 5 Metal 0x19eabdfd4 -[_MTLCommandQueue _submitAvailableCommandBuffers] + 480 6 Metal 0x19eabe4ac __40-[_MTLCommandQueue submitCommandBuffer:]_block_invoke + 24 7 libdispatch.dylib 0x180178de0 _dispatch_client_callout + 16 8 libdispatch.dylib 0x180188ac8 _dispatch_lane_barrier_sync_invoke_and_complete + 92 9 Metal 0x19eabe46c -[_MTLCommandQueue submitCommandBuffer:] + 112 10 MTLSimDriver 0x2275c5fc8 -[MTLSimCommandBuffer commitAndWaitUntilSubmitted] + 40 11 RenderBox 0x1c6e9015c RB::RenderFrame::~RenderFrame() + 240 12 RenderBox 0x1c6e6e9dc __38-[RBLayer displayWithBounds:callback:]_block_invoke.27 + 500 13 libdispatch.dylib 0x180178de0 _dispatch_client_callout + 16 14 libdispatch.dylib 0x180188ac8 _dispatch_lane_barrier_sync_invoke_and_complete + 92 15 RenderBox 0x1c6e6de38 -[RBLayer displayWithBounds:callback:] + 2480 16 RenderBox 0x1c6e6d46c -[RBLayer display] + 172 17 QuartzCore 0x18b0c7e74 CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 392 18 QuartzCore 0x18affca50 CA::Context::commit_transaction(CA::Transaction*, double, double*) + 464 19 QuartzCore 0x18b02b260 CA::Transaction::commit() + 652 20 UIKitCore 0x185af0f70 __34-[UIApplication _firstCommitBlock]_block_invoke_2 + 32 21 CoreFoundation 0x18041b58c __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 20 22 CoreFoundation 0x18041acc4 __CFRunLoopDoBlocks + 352 23 CoreFoundation 0x1804153cc __CFRunLoopRun + 812 24 CoreFoundation 0x180414c24 CFRunLoopRunSpecific + 552 25 GraphicsServices 0x19020ab10 GSEventRunModal + 160 26 UIKitCore 0x185ad82fc -[UIApplication _run] + 796 27 UIKitCore 0x185adc4f4 UIApplicationMain + 124 28 SwiftUI 0x1d290b41c closure #1 in KitRendererCommon(_:) + 164 29 SwiftUI 0x1d290b144 runApp<A>(_:) + 84 30 SwiftUI 0x1d266bef4 static App.main() + 148 31 CanvasTest.debug.dylib 0x105061c64 static CanvasTest.$main() + 40 32 CanvasTest.debug.dylib 0x105061d14 __debug_main_executable_dylib_entry_point + 12 (CanvasTest.swift:11) 33 dyld_sim 0x10519d410 start_sim + 20 34 dyld 0x10539a274 start + 2840 Thread 4:: com.apple.uikit.eventfetch-thread 0 libsystem_kernel.dylib 0x1050f5290 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x1051066c4 mach_msg2_internal + 76 2 libsystem_kernel.dylib 0x1050fd3f4 mach_msg_overwrite + 536 3 libsystem_kernel.dylib 0x1050f55cc mach_msg + 20 4 CoreFoundation 0x18041b000 __CFRunLoopServiceMachPort + 156 5 CoreFoundation 0x180415528 __CFRunLoopRun + 1160 6 CoreFoundation 0x180414c24 CFRunLoopRunSpecific + 552 7 Foundation 0x180f319c8 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 208 8 Foundation 0x180f31be8 -[NSRunLoop(NSRunLoop) runUntilDate:] + 60 9 UIKitCore 0x185b858c0 -[UIEventFetcher threadMain] + 404 10 Foundation 0x180f58810 __NSThread__start__ + 720 11 libsystem_pthread.dylib 0x10507f6f8 _pthread_start + 104 12 libsystem_pthread.dylib 0x10507a940 thread_start + 8
0
0
192
Dec ’24
Threads with classic lock-based synchronization in SwiftUI in Xcode 16
Hi, I am stuck moving one of my projects from Xcode 15 to Xcode 16. This is a SwiftUI application that uses in some places classic Threads and locks/conditions for synchronization. I was hoping that in Swift 5 mode, I could compile and run this app also with Xcode 16 so that I can start migrating it towards Swift 6. Unfortunately, my application crashes via EXC_BREAKPOINT (code=1, subcode=0x1800eb31c) whenever some blocking operation e.g. condition.wait() or DispatchQueue.main.sync { ... } is invoked from within the same module (I haven't seen this happening for frameworks that use the same code that I linked in dynamically). I have copied an abstraction below that I am using, to give an example of the kind of code I am talking about. I have verified that Swift 5 is used, "strict concurrency checking" is set to "minimal", etc. I have not found a workaround and thus, I'm curious to hear if others were facing similar challenges? Any hints on how to proceed are welcome. Thanks, Matthias Example abstraction that is used in my app. It's needed because I have synchronous computations that require a large stack. It's crashing whenever condition.wait() is executed. public final class TaskSerializer: Thread { /// Condition to synchronize access to `tasks`. private let condition = NSCondition() /// The tasks queue. private var tasks = [() -> Void]() public init(stackSize: Int = 8_388_608, qos: QualityOfService = .userInitiated) { super.init() self.stackSize = stackSize self.qualityOfService = qos } /// Don't call directly; this is the main method of the serializer thread. public override func main() { super.main() while !self.isCancelled { self.condition.lock() while self.tasks.isEmpty { if self.isCancelled { self.condition.unlock() return } self.condition.wait() } let task = self.tasks.removeFirst() self.condition.unlock() task() } self.condition.lock() self.tasks.removeAll() self.condition.unlock() } /// Schedule a task in this serializer thread. public func schedule(task: @escaping () -> Void) { self.condition.lock() self.tasks.append(task) self.condition.signal() self.condition.unlock() } }
1
0
207
Nov ’24
SwiftUI 4 navigation bug on iOS 16?
Hi everyone, I am running into a navigation-related issue that appears to be new in iOS 16/SwiftUI 4. The code below illustrates the problem: struct ContentView: View {   @State private var input: String = ""   var body: some View {     NavigationStack {       VStack {         Spacer()         NavigationLink("Navigate") {           Text("Nested View")         }         Spacer()         TextEditor(text: $input)           .border(.red)           .frame(height: 40)       }       .padding()     }   } } The initial view consists of a navigation link and a text editor at the bottom of the screen. I run the app on an iPhone (or the simulator) in iOS 16 and click on the text editor at the bottom of the screen. This invokes the virtual keyboard, which pushes up the text field. Next, I click on "Navigate" to navigate to the nested view. I navigate immediately back, which brings back the initial view without the keyboard. Unfortunately, the text field isn't pushed back to the bottom and is now located in the middle of the screen. (see attached image) Did anyone experience similar issues? Is there a workaround I could use to force a re-layout of the initial view upon return from the navigation link? Thanks, Matthias
8
2
3.3k
Sep ’22
Freeze when deallocating large data structures
Hi everyone, I have encountered a strange Swift runtime crash/freeze when large data structures created from recursive enums with associated values are automatically deallocated. I am unable to debug this issue and I was wondering if anyone has some advice on what to do here? Here's my code: enum MyList {   case empty   indirect case pair(MyList, MyList) } var lst = MyList.empty for _ in 0..<150000 {   lst = .pair(.empty, lst) } print("Done creating list") lst = .empty print("Completed program (this is never printed)") This code uses an enum to represent a simple linear list. The loop creates 150,000 linearly linked nodes and ultimately prints "Done creating list". The following statement (which implicitly deallocates the long list) never returns. This is where I am stuck. It seems to be impossible to deallocate such a data structure without the Swift runtime freezing. Any help is appreciated! == Matthias
3
0
1k
Nov ’21