Since this issue is still happening 3 years later on macOS 14.6.1, I stumbled again on this post and I see only now that you asked for the bug number, but unfortunately I didn't subscribe to this post back then and wasn't notified of your reply. It's FB8979522.

How do you use the Quick Look Simulator? When I run my Quick Look Preview Extension in Xcode, that app opens but it only shows a search field.

[quote='797102022, DTS Engineer, /thread/760029?answerId=797102022#797102022'] If you only want to look at the app, rather than run it, you can ignoer the whole thing: [/quote] So I ran lldb ~/Library/Developer/Xcode/Archives/2024-07-12/MyApp\ macOS\ 12.07.2024\,\ 20.43.xcarchive/Products/Applications/MyApp.app To translate the addresses from the crash report to lldb, it wasn't sufficient to subtract the binary image base address, but I found some help at Symbolicating with LLDB. By running lldb image list which outputs [ 0] 2521131E-2080-387D-B96E-8DB6AA18E011 0x0000000100000000 ~/Library/Developer/Xcode/Archives/2024-07-12/MyApp macOS 12.07.2024, 20.43.xcarchive/Products/Applications/MyApp.app/Contents/MacOS/MyApp /System/Volumes/Data/~/Library/Developer/Xcode/Archives/2024-07-12/MyApp macOS 12.07.2024, 20.43.xcarchive/dSYMs/MyApp.app.dSYM/Contents/Resources/DWARF/MyApp [ 1] 37BBC384-0755-31C7-A808-0ED49E44DD8E 0x00000001800b8000 /usr/lib/dyld ... I found out that there is another base address here 0x0000000100000000 (which almost looks like 0x0) that I also have to subtract. So the real offset is 0x104468000 - 0x0000000100000000 = 0x004468000 which I could set with lldb target modules load --file MyApp --slide 0x004468000 So now I can disassemble by directly providing the addresses from the crash report, and I confirm that all crash report addresses point to the correct symbol names. But when I run lldb disas -a 0x00000001044fff28 (where 0x00000001044fff28 is the address for the call to MyViewController.myModalAction in the crash report), I get this relatively short and rather obscure output: MyApp`merged @objc MyApp.MyViewController.myModalAction(Any) -> (): 0x1044ffed8 <+0>: sub sp, sp, #0x50 0x1044ffedc <+4>: stp x22, x21, [sp, #0x20] 0x1044ffee0 <+8>: stp x20, x19, [sp, #0x30] 0x1044ffee4 <+12>: stp x29, x30, [sp, #0x40] 0x1044ffee8 <+16>: add x29, sp, #0x40 0x1044ffeec <+20>: mov x19, x3 0x1044ffef0 <+24>: mov x20, x2 0x1044ffef4 <+28>: mov x21, x0 0x1044ffef8 <+32>: mov x0, x2 0x1044ffefc <+36>: bl 0x1001d6a60 ; symbol stub for: swift_unknownObjectRetain 0x1044fff00 <+40>: mov x0, x21 0x1044fff04 <+44>: bl 0x1001d6664 ; symbol stub for: objc_retain 0x1044fff08 <+48>: mov x21, x0 0x1044fff0c <+52>: mov x8, sp 0x1044fff10 <+56>: mov x0, x20 0x1044fff14 <+60>: bl 0x1001d5ee4 ; symbol stub for: Swift._bridgeAnyObjectToAny(Swift.Optional<Swift.AnyObject>) -> Any 0x1044fff18 <+64>: mov x0, x20 0x1044fff1c <+68>: bl 0x1001d6a54 ; symbol stub for: swift_unknownObjectRelease 0x1044fff20 <+72>: mov x20, x21 0x1044fff24 <+76>: blr x19 0x1044fff28 <+80>: mov x0, sp 0x1044fff2c <+84>: bl 0x100008ce4 ; __swift_destroy_boxed_opaque_existential_0 at <compiler-generated> 0x1044fff30 <+88>: mov x0, x21 0x1044fff34 <+92>: bl 0x1001d6658 ; symbol stub for: objc_release 0x1044fff38 <+96>: ldp x29, x30, [sp, #0x40] 0x1044fff3c <+100>: ldp x20, x19, [sp, #0x30] 0x1044fff40 <+104>: ldp x22, x21, [sp, #0x20] 0x1044fff44 <+108>: add sp, sp, #0x50 0x1044fff48 <+112>: ret Whereas if I run lldb disas -n myModalAction I get a way longer output which contains the expected calls to my own other methods, starting with MyApp`MyViewController.myModalAction(_:): 0x1044f9578 <+0>: stp x28, x27, [sp, #-0x60]! ... Notice how the first lines of these two outputs differ: MyApp`merged @objc MyApp.MyViewController.myModalAction(Any) -> () vs MyApp`MyViewController.myModalAction(_:) What does this difference mean? The line in the crash report 13 MyApp 0x00000001044fff28 @objc MyViewController.myModalAction(_:) + 80 is the only one that doesn't make sense and couldn't possibly call the line above it.

[quote='797039022, DTS Engineer, /thread/760029?answerId=797039022#797039022'] you can use the Xcode organiser to export a development-signed version of your app [/quote] I selected the archive in the Xcode Organizer, clicked Distribute App > Custom > Debugging > Automatically Manage Signing > Export. Then launched the exported app from the Finder and in Xcode selected Debug > Attach to Process. It still gives me the exact same error as before, with the exact same Console messages. That’ll have the same code as the original app — including the same LC_UUID values — but with the code signing set up for development Does that mean that the entitlements file is actually modified when creating the archive? I ran the Terminal command codesign -d --entitlements - --xml /path/to/exported/app but it has the same entitlements as before.

I was looking forward to using lldb, but both when running the Terminal command or trying to attach from my running app in Xcode I get an error process exited with status -1 (attach failed (Not allowed to attach to process. Look in the console messages (Console.app), near the debugserver entries, when the attach failed. The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.)) And the Console shows these messages: 3898 debugserver default 13:45:23.707652+0200 debugserver will use os_log for internal logging. 3898 debugserver default 13:45:23.708012+0200 debugserver-@(#)PROGRAM:LLDB PROJECT:lldb-1500.0.404.7 for arm64. 3898 debugserver default 13:45:23.708050+0200 Got a connection, waiting for process information for launching or attaching. 3898 debugserver default 13:45:23.708297+0200 [LaunchAttach] START 3898 vAttach to pid 605 3898 debugserver default 13:45:23.708436+0200 [LaunchAttach] (3898) about to task_for_pid(605) 3898 debugserver errore 13:45:23.708472+0200 error: [LaunchAttach] MachTask::TaskPortForProcessID task_for_pid(605) failed: ::task_for_pid ( target_tport = 0x0203, pid = 605, &task ) => err = 0x00000005 ((os/kern) failure) 3898 debugserver default 13:45:23.708484+0200 1 +0.000000 sec [0f3a/0103]: error: ::task_for_pid ( target_tport = 0x0203, pid = 605, &task ) => err = 0x00000005 ((os/kern) failure) err = ::task_for_pid ( target_tport = 0x0203, pid = 605, &task ) => err = 0x00000005 ((os/kern) failure) (0x00000005) 3898 debugserver default 13:45:23.719499+0200 [LaunchAttach] (3898) about to task_for_pid(605) 3898 debugserver errore 13:45:23.719532+0200 error: [LaunchAttach] MachTask::TaskPortForProcessID task_for_pid(605) failed: ::task_for_pid ( target_tport = 0x0203, pid = 605, &task ) => err = 0x00000005 ((os/kern) failure) 3898 debugserver default 13:45:23.719543+0200 2 +0.011059 sec [0f3a/0103]: error: ::task_for_pid ( target_tport = 0x0203, pid = 605, &task ) => err = 0x00000005 ((os/kern) failure) err = ::task_for_pid ( target_tport = 0x0203, pid = 605, &task ) => err = 0x00000005 ((os/kern) failure) (0x00000005) and so on. The rest is attached as a text file, putting it inline in this reply shows a validation error "Your reply must include text in the body." (for which I created FB14466890). Console logs At first I tried 3 times from the Terminal, but each time the Mac stopped responding after a couple seconds and after a couple minutes restarted automatically (after the third time I created FB14466119). Xcode didn't freeze the Mac, but instead showed a button "report issue", which I clicked and automatically generated FB14466745.

Thanks for your insights. I created FB14466634 regarding the documentation. So does this mean that it would be impossible to port that sample project to iOS, since the network extension has no way of communicating with the app, i.e. it would be impossible to build an iOS app that shows network flows or allows to reject flows from real-time user input?

Thanks, I just tried that. Then I realized that I can barely see any of my app's symbol names in the disassembly (which I created with otool -vt /path/to/executable). For instance I cannot find any of the method names mentioned in the crash reports. The disassembly looks like this: ~/Library/Developer/Xcode/Archives/2024-07-12/MyApp macOS 12.07.2024, 20.43.xcarchive/Products/Applications/MyApp.app/Contents/MacOS/MyApp (architecture arm64): (__TEXT,__text) section 0000000100004a00 stp x20, x19, [sp, #-0x20]! 0000000100004a04 stp x29, x30, [sp, #0x10] 0000000100004a08 add x29, sp, #0x10 0000000100004a0c adrp x8, 567 ; 0x10023b000 0000000100004a10 ldr x0, [x8, #0xc30] ; Objc class ref: bad class ref 0000000100004a14 bl 0x1001d664c ; symbol stub for: _objc_opt_self 0000000100004a18 adrp x8, 567 ; 0x10023b000 0000000100004a1c ldr x1, [x8, #0x588] ; Objc selector ref: sharedApplication 0000000100004a20 bl 0x1001d6634 ; Objc message: -[x0 sharedApplication] 0000000100004a24 mov x29, x29 0000000100004a28 bl 0x1001d667c ; symbol stub for: _objc_retainAutoreleasedReturnValue 0000000100004a2c adrp x19, 587 ; 0x10024f000 0000000100004a30 str x0, [x19, #0xb30] 0000000100004a34 mov x0, #0x0 0000000100004a38 bl 0x1000e6c04 0000000100004a3c bl 0x1001d6604 ; symbol stub for: _objc_allocWithZone ... When you wrote disassemble the code pointed to be the backtrace to make sure it’s the thunk that you expect it to be were you thinking of a particular command that creates disassemblies with symbol names, or how would you "make sure it's the thunk that you expect it to be"?

I opened FB13712968 back in April, but didn't get any response so far. I know this is a weird why question, but I thought maybe there's a known reason I'm ignoring.

[quote='796605022, DTS Engineer, /thread/760029?answerId=796605022#796605022'] I usually investigate issues like this at the assembly level [/quote] Thanks. I never did this before and I wasn't able to find anything helpful on the internet. otool can disassemble, but of course the addresses are different than those in the crash report. Is there a way to easily map the addresses, or are there better Terminal tools for this?

[quote='796453022, DTS Engineer, /thread/760029?answerId=796453022#796453022'] This shows how the ns as! [MyElement] cast is done lazily [/quote] Thanks, this already helped me reproduce and fix the second crash. The array was coming from a token field's objectValue. Regarding the first crash, I noticed something strange. The crash report seems to imply that a particular method called another one, which is impossible. Let me show and explain to you the rest of the stacktrace: ... Code Type: ARM-64 Parent Process: launchd [1] User ID: 501 Date/Time: 2024-07-18 14:59:40.4375 +0800 OS Version: macOS 15.0 (24A5289h) ... Crashed Thread: 0 Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000001, 0x00000001045048b8 Termination Reason: Namespace SIGNAL, Code 5 Trace/BPT trap: 5 Terminating Process: exc handler [1771] Thread 0 Crashed: 0 MyApp 0x00000001045048b8 specialized Collection.map<A>(_:) + 596 1 MyApp 0x00000001045011e4 MyViewController.validateToolbarButtons() + 648 (MyViewController.swift:742) ... 12 MyApp 0x00000001044fcef4 MyViewController.myOtherAction(_:) + 184 (MyViewController.swift:455) 13 MyApp 0x00000001044fff28 @objc MyViewController.myModalAction(_:) + 80 14 AppKit 0x000000019e2ae13c -[NSApplication(NSResponder) sendAction:to:from:] + 460 15 AppKit 0x000000019e375b08 -[NSMenuItem _corePerformAction] + 372 16 AppKit 0x000000019ea4be30 _NSMenuPerformActionWithHighlighting + 152 17 AppKit 0x000000019e3ad5d0 -[NSMenu performActionForItemAtIndex:] + 200 18 AppKit 0x000000019e3ad4f0 -[NSMenu _internalPerformActionForItemAtIndex:] + 76 19 AppKit 0x000000019ea4204c +[NSCocoaMenuImpl _performActionForMenuItem:] + 176 20 AppKit 0x000000019e84ff58 -[NSMenuTrackingSession _performPostTrackingDismissalActions] + 268 21 AppKit 0x000000019e84fc60 -[NSMenuTrackingSession startRunningMenuEventLoop:] + 1332 22 AppKit 0x000000019e84f6d0 -[NSMenuTrackingSession startMonitoringEvents:] + 256 23 AppKit 0x000000019efe5d78 -[NSContextMenuTrackingSession startMonitoringEvents:] + 144 24 AppKit 0x000000019e8048f8 +[NSContextMenuImpl presentPopup:fromView:withContext:animated:] + 848 25 AppKit 0x000000019ea4d5ec _NSPopUpMenu + 2128 26 AppKit 0x000000019ea51cbc -[NSCocoaMenuImpl _popUpContextMenu:withEvent:forView:withFont:] + 304 27 AppKit 0x000000019e429acc -[NSMenu _popUpContextMenu:withEvent:forView:withFont:] + 208 28 AppKit 0x000000019ece4658 -[NSView _showMenuForEvent:] + 72 29 AppKit 0x000000019e425ff4 -[NSView rightMouseDown:] + 76 30 AppKit 0x000000019e7225e0 -[NSControl _rightMouseUpOrDown:] + 352 31 AppKit 0x000000019ed81ec4 _routeRightMouseDownEvent + 264 32 AppKit 0x000000019e2348f8 -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 420 33 AppKit 0x000000019e234584 -[NSWindow(NSEventRouting) sendEvent:] + 284 34 AppKit 0x000000019ea1f568 -[NSApplication(NSEventRouting) sendEvent:] + 1656 35 AppKit 0x000000019e632b78 -[NSApplication _handleEvent:] + 60 36 AppKit 0x000000019e100914 -[NSApplication run] + 520 37 AppKit 0x000000019e0d7094 NSApplicationMain + 888 38 MyApp 0x000000010446ca80 main + 128 (main.swift:12) 39 dyld 0x000000019a16b274 start + 2840 The ellipsis only hides methods from my own classes. Directly below it, it would seem that @objc MyViewController.myModalAction(_:), which shows an app modal window, somehow calls MyViewController.myOtherAction(_:), but myOtherAction can only be called by a menu or the press of a toolbar button which are both disabled by the modal window shown by myModalAction. Does this mean that myOtherAction is called somehow when the modal window opened by myModalAction is closed? Another interesting point: I don't know why myModalAction is prefixed with @objc, since both are declared as @IBAction func methodName(_ sender: Any). The only difference is that myModalAction is set as a table view's doubleAction, but from the rest of the stacktrace it seems like myModalAction is called by a menu.

Thanks. The part I was missing is the one the documentation for NSTextContentManager doesn't mention, which is that it is an abstract class whose (apparently) only concrete subclass is NSTextContentStorage, which has a textStorage property. guard let textStorage: NSTextStorage = (textLayoutManager?.textContentManager as? NSTextContentStorage)?.textStorage else { return } The sample code also changes the textStorage inside the block passed to textContentManager.performEditingTransaction(_:), which the documentation doesn't seem to explain why it's necessary.

I just wanted to add that for some reason the order of imports inside the test files is important in some cases. I have to write: @testable import MyApp import XCTest Inverting those two lines causes several compiler errors inside the bridging header file: Redefinition of 'vtype' Redefinition of enumerator 'VBAD' Redefinition of enumerator 'VBLK' ... I have no idea why this happens, as in another project with the exact same bridging header file the order of imports seems to be irrelevant and doesn't cause any compiler errors.

Did you find a solution? I'm having the same issue on macOS 10.14.

NSTableRowView has a property backgroundColor, but this is also used by AppKit when you set tableView.usesAlternatingRowBackgroundColors = true. The only way I could make it work was by returning a custom row view subclass and dynamically returning a custom background color. class MyRowView: NSTableRowView { var myBackgroundColor: NSColor? override var backgroundColor: NSColor { get { return myBackgroundColor ?? super.backgroundColor } set { super.backgroundColor = newValue } } } and in the delegate func outlineView(_ outlineView: NSOutlineView, didAdd rowView: NSTableRowView, forRow row: Int) { if myCondition { (rowView as! MyRowView).myBackgroundColor = myColor } }

I opened FB13907122. I will ask the customer if they are able to share a sysdiagnose with me when they get back to me.