I was able to verify the above backtrace is really the offending log: (lldb) po $x0 6935281664 (lldb) po $x1 <OS_os_log: 0x12b7acdc0> (lldb) po $x2 17 (lldb) po $x3 6936223887 (lldb) po $x4 6157865216 (lldb) po $x5 22 (lldb) po $x6 6149505024 (lldb) po $x7 1 (lldb) x/s $x3 0x19d6e608f: "CLIENT ERROR: %@ does not override -%@ and thus cannot react to catastrophic errors beyond logging them" (lldb) x/22bx $x4 0x16f099100: 0x02 0x02 0x40 0x08 0x50 0x7a 0x21 0x6e 0x16f099108: 0x02 0x00 0x00 0x00 0x40 0x08 0x50 0xef 0x16f099110: 0x66 0x2f 0x01 0x00 0x00 0x00 (lldb) po 0x000000012f66ef50 viewServiceDidTerminateWithError: (lldb) po 0x000000026e217a50 TUINSRemoteViewController

Both my son and I hit this every day on different projects. Nothing in NSViewController.h even returns a NSError, so I am really puzzled about what I'm missing. But yes, it does seem to be related to interacting with a NSTextField. MacOS 14.5 23F79, Xcode 15.4 Mac App I was able to get it to stop at or about the point the error is emitted by breaking on _os_log_fault_impl. The code path is triggered when I clicked in a NSTextField shortly after (my) app launch without doing anything else. The text field is empty. os_log_fault gave this backtrace: (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 18.1 * frame #0: 0x0000000194b383c8 libsystem_trace.dylib`_os_log_fault_impl frame #1: 0x000000019d6ad0bc ViewBridge`-[NSRemoteViewControllerAuxiliary viewDidInvalidate:].cold.2 + 92 frame #2: 0x000000019d692e7c ViewBridge`-[NSRemoteViewControllerAuxiliary viewDidInvalidate:] + 452 frame #3: 0x000000019d6675e0 ViewBridge`-[NSRemoteView invalidate] + 284 frame #4: 0x000000024f39b0dc TextInputUIMacHelper`-[TUINSWindow setRemoteViewController:] + 128 frame #5: 0x000000024f39c12c TextInputUIMacHelper`__36-[TUINSCursorUIController activate:]_block_invoke.120 + 272 frame #6: 0x000000019d692c04 ViewBridge`-[NSRemoteViewControllerAuxiliary viewDidAdvanceToRunPhase:] + 56 frame #7: 0x000000019d67cffc ViewBridge`-[NSRemoteView _lastCallImpliedByAdvancingToPhase:] + 228 frame #8: 0x0000000194ea2694 CoreFoundation`__invoking___ + 148 frame #9: 0x0000000194ea2514 CoreFoundation`-[NSInvocation invoke] + 428 frame #10: 0x000000019d612be8 ViewBridge`__deferNSXPCInvocationOntoMainThread_block_invoke + 120 frame #11: 0x000000019d607eb4 ViewBridge`__wrapBlockWithVoucher_block_invoke + 56 frame #12: 0x000000019d6a7a78 ViewBridge`deferredBlockOpportunity_block_invoke_2 + 360 frame #13: 0x0000000194ec2070 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 28 frame #14: 0x0000000194ec1f84 CoreFoundation`__CFRunLoopDoBlocks + 356 frame #15: 0x0000000194ec1414 CoreFoundation`__CFRunLoopRun + 2440 frame #16: 0x0000000194ec0434 CoreFoundation`CFRunLoopRunSpecific + 608 frame #17: 0x000000019f66419c HIToolbox`RunCurrentEventLoopInMode + 292 frame #18: 0x000000019f663fd8 HIToolbox`ReceiveNextEventCommon + 648 frame #19: 0x000000019f663d30 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 76 frame #20: 0x000000019871fd68 AppKit`_DPSNextEvent + 660 frame #21: 0x0000000198f15808 AppKit`-[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 700 frame #22: 0x00000001991080a0 AppKit`-[NSTextView _bellerophonTrackMouseWithMouseDownEvent:originalSelection:granularity:extending:rectangular:toggling:multiple:checkForLink:autoscrollEvent:] + 856 frame #23: 0x0000000198a32264 AppKit`-[NSTextView mouseDown:] + 3104 frame #24: 0x00000001989c0cb0 AppKit`-[NSTextField mouseDown:] + 280 frame #25: 0x00000001988c0dcc AppKit`-[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] + 3472 frame #26: 0x000000019884c40c AppKit`-[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 288 frame #27: 0x000000019884c118 AppKit`-[NSWindow(NSEventRouting) sendEvent:] + 284 frame #28: 0x0000000198f14828 AppKit`-[NSApplication(NSEventRouting) sendEvent:] + 1604 frame #29: 0x0000000198b6289c AppKit`-[NSApplication _handleEvent:] + 60 frame #30: 0x00000001987130c0 AppKit`-[NSApplication run] + 512 frame #31: 0x00000001986ea2e0 AppKit`NSApplicationMain + 880 frame #32: 0x000000010222389c MechanusBRP`main(argc=3, argv=0x000000016dbff3c0) at main.m:15:12 frame #33: 0x0000000194a5a0e0 dyld`start + 2360 (lldb) c Process 24764 resuming CLIENT ERROR: TUINSRemoteViewController does not override -viewServiceDidTerminateWithError: and thus cannot react to catastrophic errors beyond logging them My assumption here is that we are doing something wrong (e.g. overlapping views or maybe some method is not wired up that needs to be, or didn't set up something in the controller hierarchy that we should have, etc.) The problem is that the warning seems geared towards Apple internal development and the rest of us are just left scratching our head wondering what this could be about. So if nothing else, perhaps an engineer might gaze lovingly at the error message and see if it could perhaps be made to be a bit more helpful. A few hints dropped here would be lovely as well so we could move forward with whatever it is we forgot to wire up. FWIW: I don't think choice of language is relevant here. We see it in a pair of objc++ apps. It also doesn't seem to matter about display. I see it with my MBP M1 clamshell closed on an Apple Studio display. My son sees it on a MBP M3 clamshell open on the onboard display. I haven't looked at other configurations. (Both are HDR displays though. Clearly you need HDR display for "testing"! Contact your manager.)

I had this problem and overrode -makeKeyWindow and set a breakpoint to see how I got there: @interface AssistedTextFieldWindow : NSWindow @end @implementation AssistedTextFieldWindow -(void) makeKeyWindow { [super makeKeyWindow]; // break here } @end (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 38.1 frame #0: 0x000000010491bb90 BRP Character`-[AssistedTextFieldWindow makeKeyWindow](self=0x0000000154e22270, _cmd="makeKeyWindow") at AssistedTextField.m:19:5 frame #1: 0x00000001967aac4c AppKit`-[NSWindow _makeKeyRegardlessOfVisibility] + 56 frame #2: 0x00000001967a332c AppKit`-[NSWindow makeKeyAndOrderFront:] + 24 * frame #3: 0x000000010491c578 BRP Character`-[AssistedTextField didMakeFirstResponder:](self=0x0000000154f0e2f0, _cmd="didMakeFirstResponder:", obj=@"DidMakeFirstResponder") at AssistedTextField.m:132:29 Looking at AssistedTextField.m:132 I have: windowController.window.isVisible = YES; So that's how I got here. What to do about it? I have no idea.

I ran into some troubles like this today. The build would work, but the side builds it does to find errors as you are typing were failing and spewing lots of errors that all start with XCTest/XCTest.h not found. (Xcode 15.3). I added /Library/Frameworks (recursive) to the project's framework search path and the issue went away.

The Problem Obvious answer was that when connecting, you are supposed to fill out the sockaddr structure yourself. There is apparently no API for this, and my attempts to find one above just sent me down a rabbit hole that returned a const sockaddr structure without a port field. This is not the only variant of the sockaddr structure, however. There are also sockaddr_in and sockaddr_in6 which are both more suitable for this use. I was able to make my own struct, copy in the bits the OS provided then set the port and move on. I'm sure it is entirely understood by the experts in the art just how crufty this is by current API standards so I won't bedevil the point but at least in my newbie perspective this and the ridiculous endianness patch for the port was on the level of "Don't drink the water" and "Don't feed the grizzly bears" -- the sort of cultural information that your language professor reveals with evident glee because it justifies perpetual employment in any economy, that would otherwise be a unwelcome trap for the strangers in a strange land, to the level of "Why would I even want to visit?" had they known. I'm not sure this has a place in well designed API, but it is culture at this point, I am sure, and obviously not under Apple's control. In any event, this seems to work for me, should any other woe begotten travelers find themselves detoured on this path. // My DNSServiceGetAddrInfoReply void ServiceList::Node::AddressInfoCallback( DNSServiceRef __nonnull _sdRef, DNSServiceFlags _flags, uint32_t _interfaceIndex, DNSServiceErrorType _errorCode, const char * __nullable _hostname, const struct sockaddr * __nullable _address, uint32_t UNUSED _ttl, void * __nonnull context) { AddrInfo * info = (AddrInfo*) context; if( kDNSServiceErr_NoError != _errorCode || NULL == _hostname || NULL == _address) { LOG_ERROR("Failed to get address info on \"%s\"\n", (const char*) info->hostTarget); delete info; return; } // set the port union { sockaddr_in in; sockaddr_in6 in6; } addrs; memset( &addrs, 0, sizeof(addrs)); socklen_t addrsSize = 0; switch( _address->sa_len) { case sizeof( sockaddr_in): addrsSize = sizeof(addrs.in); memcpy( &addrs.in, _address, addrsSize); addrs.in.sin_port = htons(info->port); // big endian. Because, obviously... break; case sizeof( sockaddr_in6): addrsSize = sizeof(addrs.in6); memcpy( &addrs.in6, _address, addrsSize); addrs.in6.sin6_port = htons(info->port); break; default: LOG_ERROR("Unhandled sockaddr variant"); return; } int err = connect(info->socket, (sockaddr*) &addrs, addrsSize); ....