also having crash in Xcode if I leave it open (either just open, or running a debug session searching for an intermediate memory leak). MacBookPro, M1 Pro. Xcode 15.0.1 and macOS 14.1.2.
Translated Report (Full Report Below)
Process: Xcode [2834]
Path: /Applications/Xcode.app/Contents/MacOS/Xcode
Identifier: com.apple.dt.Xcode
Version: 15.0.1 (22266)
Build Info: IDEApplication-22266000000000000~15 (15A507)
App Item ID: 497799835
App External ID: 860559424
Code Type: ARM-64 (Native)
Parent Process: launchd [1]
User ID: 501
Date/Time: 2023-12-04 13:01:29.5210 -0800
OS Version: macOS 14.1.2 (23B92)
Report Version: 12
Anonymous UUID: 94D9A24C-E6F8-6B77-2714-5078DBEBF8C7
Time Awake Since Boot: 180000 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x0000000189fbe244
Termination Reason: Namespace SIGNAL, Code 5 Trace/BPT trap: 5
Terminating Process: exc handler [2834]
Application Specific Information:
BUG IN CLIENT OF LIBPLATFORM: os_unfair_lock is corrupt
Abort Cause 15708772
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_platform.dylib 0x189fbe244 _os_unfair_lock_corruption_abort + 88
1 libsystem_platform.dylib 0x189fb9788 os_unfair_lock_lock_slow + 332
2 Foundation 0x18b1633f4 NSSetLongLongValueAndNotify + 84
3 DVTFoundation 0x104643910 closure #1 in DVTCoreDevice.endPreparationOperation(::) + 96
4 DVTFoundation 0x1045d2a48 thunk for @escaping @callee_guaranteed () -> () + 28
5 DVTFoundation 0x104577330 DVT_CALLING_CLIENT_BLOCK + 16
6 DVTFoundation 0x104577cf0 __DVTDispatchAsync_block_invoke + 48
7 libdispatch.dylib 0x189dddcb8 _dispatch_call_block_and_release + 32
8 libdispatch.dylib 0x189ddf910 _dispatch_client_callout + 20
9 libdispatch.dylib 0x189dedfa8 _dispatch_main_queue_drain + 984
10 libdispatch.dylib 0x189dedbc0 _dispatch_main_queue_callback_4CF + 44
11 CoreFoundation 0x18a0ab15c CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE + 16
12 CoreFoundation 0x18a068a80 __CFRunLoopRun + 1996
13 CoreFoundation 0x18a067c5c CFRunLoopRunSpecific + 608
14 HIToolbox 0x1945e4448 RunCurrentEventLoopInMode + 292
15 HIToolbox 0x1945e40d8 ReceiveNextEventCommon + 220
16 HIToolbox 0x1945e3fdc _BlockUntilNextEventMatchingListInModeWithFilter + 76
17 AppKit 0x18d842c54 _DPSNextEvent + 660
18 AppKit 0x18e018ebc -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 716
19 DVTKit 0x1033e8a9c -[DVTApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 300
20 AppKit 0x18d836100 -[NSApplication run] + 476
21 DVTKit 0x1033e7cbc -[DVTApplication run] + 60
22 AppKit 0x18d80d3cc NSApplicationMain + 880
23 dyld 0x189c110e0 start + 2360
parker9
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
Post
Replies
Boosts
Views
Activity
I couldn't figure out how to do either one. So, after downloading, I simply open a Finder window with the update highlighted. I'll leave it up to the user to figure out the rest.
Turns out it has nothing to do with main.swift. I have a dictionary defined as dict : [ CGWindowID : NSWindow]. if you do dict.removeValue(forKey: key)?.close() this double deallocates the NSWindow if dict[key] was the last strong reference.
Found this by instead of Run in Xcode, you do Profile and select Zombie and I found that this NSWindow reference count goes to -1. oops.
Nope, same crash as before....
Should have said "Status menu item" instead of "menu item". Regardless, changed main.swift to this:
import Cocoa
let app = NSApplication.shared
let delegate = AppDelegate()
withExtendedLifetime(delegate, {
app.delegate = delegate
app.run()
app.delegate = nil
})
seems to fix the occasional crash. This just forces a hard link to AppDelegate() so it doesn't get deallocated, apparently.
You can figure out which Desktops go with which Screens by comparing their CGRect (be careful, some CGRect has the vertical axis direction flipped- see https://entonos.com/index.php/2021/05/20/which-cgrect-was-that/).
However, I have yet to figure out which Space corresponds to which Desktop (or vice versa). The best I've found is to ask CoreGraphics if a Desktop window is currently on screen. You then know that Desktop is on the current Space. Of course, you don't know which Space you're actually on.
There doesn't appear to be any public API to do this. Searching GitHub, there are some codes that do this, but they are using non-public API (e.g. using CGSCopyManagedDisplaySpaces)
let window : NSWindow? = nil
...
window?.collectionBehavior = .canJoinAllSpaces // window will be in all Spaces
window?.collectionBehavior = .moveToActiveSpace // when window is activated, move to active Space
window?.collectionBehavior = .stationary // Expose doesn't affect window, so it stays visible and stationary, like the Desktop window
window?.collectionBehavior = .managed // window participates in Spaces and Expose (i.e. normal window).
there are other options....
Thanks for your response. https://feedbackassistant.apple.com/feedback/9824294
By definition the bug only occurs occasionally. Gave a link to the code and the line to comment out to get the problem to appear. Unfortunately, there is no deterministic way to reproduce.
One clue is when the code starts, it always captures the Desktop background images correctly. It seems to fail only when the NSWorkspace.activeSpaceDidChangeNotification is sent. Introducing a block for 0.25 seconds seems to insure the image capture succeeds.
Would prefer a better option than blocking.
I worked this out: https://entonos.com/index.php/2019/09/13/dice-orientations-and-quaternions/