Crash when unlock the screen #771
Labels
bug
Something isn't working as expected
Comments
|
I have no idea yet what could cause this crash, but the code that crashes is part of the fix from #445 The only circumstances the code in the stacktrace could be running is when you the screen is locked (or at least it's the only realistic circumstances known to me when macOS reuses window IDs from old closed windows for newly opened windows)
|
|
I had the same issue twice already. It happened when I locked my Mac for the night with two displays connected, but in the morning, after turning the power back on, the aerospace was already in the crashed state. I had around five windows open. |
nikitabobko
changed the title
|
Can you also please attach crash report from |
1st2nd |
This comment was marked as duplicate.
This comment was marked as duplicate.
|
I still have no idea why it happens, and I still can't reproduce it. If somebody is up for the journey, you can try to build AeroSpace from sources with the following patch with the debugger attached (I recommend using Xcode): diff --git a/Sources/AppBundle/GlobalObserver.swift b/Sources/AppBundle/GlobalObserver.swift
index 9f3cfd7..91736bb 100644
--- a/Sources/AppBundle/GlobalObserver.swift
+++ b/Sources/AppBundle/GlobalObserver.swift
@@ -4,9 +4,9 @@ class GlobalObserver {
private static func onNotif(_ notification: Notification) {
// Third line of defence against lock screen window. See: closedWindowsCache
// Second and third lines of defence are technically needed only to avoid potential flickering
- if (notification.userInfo?[NSWorkspace.applicationUserInfoKey] as? NSRunningApplication)?.bundleIdentifier == lockScreenAppBundleId {
- return
- }
+ // if (notification.userInfo?[NSWorkspace.applicationUserInfoKey] as? NSRunningApplication)?.bundleIdentifier == lockScreenAppBundleId {
+ // return
+ // }
refreshAndLayout(screenIsDefinitelyUnlocked: false)
}
diff --git a/Sources/AppBundle/layout/refresh.swift b/Sources/AppBundle/layout/refresh.swift
index 34023bb..add23a7 100644
--- a/Sources/AppBundle/layout/refresh.swift
+++ b/Sources/AppBundle/layout/refresh.swift
@@ -60,11 +60,11 @@ private func gc() {
func gcWindows() {
// Second line of defence against lock screen. See the first line of defence: closedWindowsCache
// Second and third lines of defence are technically needed only to avoid potential flickering
- if NSWorkspace.shared.frontmostApplication?.bundleIdentifier == lockScreenAppBundleId { return }
+ // if NSWorkspace.shared.frontmostApplication?.bundleIdentifier == lockScreenAppBundleId { return }
let toKill = MacWindow.allWindowsMap.filter { $0.value.axWindow.containingWindowId() == nil }
// If all windows are "unobservable", it's highly propable that loginwindow might be still active and we are still
// recovering from unlock
- if toKill.count == MacWindow.allWindowsMap.count { return }
+ // if toKill.count == MacWindow.allWindowsMap.count { return }
for window in toKill {
window.value.garbageCollect(skipClosedWindowsCache: false)
}
diff --git a/Sources/AppBundle/tree/MacApp.swift b/Sources/AppBundle/tree/MacApp.swift
index 936413e..da39d5a 100644
--- a/Sources/AppBundle/tree/MacApp.swift
+++ b/Sources/AppBundle/tree/MacApp.swift
@@ -19,9 +19,9 @@ final class MacApp: AbstractApp {
fileprivate static func get(_ nsApp: NSRunningApplication) -> MacApp? {
// Don't perceive any of the lock screen windows as real windows
// Otherwise, false positive ax notifications might trigger that lead to gcWindows
- if nsApp.bundleIdentifier == lockScreenAppBundleId {
- return nil
- }
+ // if nsApp.bundleIdentifier == lockScreenAppBundleId {
+ // return nil
+ // }
let pid = nsApp.processIdentifier
if let existing = allAppsMap[pid] {
return existingThe patch removes all heuristic code that tries to detect locked screen. By droping the heuristics you should make the crash more probable to reproduce (In the best case scenario, it should make the bug 100% reproducible) The problematic line of code is: It should never crash because The low effort fix for the crash could be: diff --git a/Sources/AppBundle/tree/TreeNode.swift b/Sources/AppBundle/tree/TreeNode.swift
index 2ea3775..d3c661e 100644
--- a/Sources/AppBundle/tree/TreeNode.swift
+++ b/Sources/AppBundle/tree/TreeNode.swift
@@ -89,7 +89,8 @@ class TreeNode: Equatable {
return result
}
- private func unbindIfBound() -> BindingData? {
+ @discardableResult
+ func unbindIfBound() -> BindingData? {
guard let _parent else { return nil }
let index = _parent._children.remove(element: self) ?? errorT("Can't find child in its parent")
diff --git a/Sources/AppBundle/tree/frozen/closedWindowsCache.swift b/Sources/AppBundle/tree/frozen/closedWindowsCache.swift
index 1e9539f..db0ff5c 100644
--- a/Sources/AppBundle/tree/frozen/closedWindowsCache.swift
+++ b/Sources/AppBundle/tree/frozen/closedWindowsCache.swift
@@ -65,7 +65,7 @@ func restoreClosedWindowsCacheIfNeeded(newlyDetectedWindow: Window) -> Bool {
MacWindow.get(byId: frozenWindow.id)?.bindAsFloatingWindow(to: workspace)
}
let orphans = workspace.rootTilingContainer.allLeafWindowsRecursive
- workspace.rootTilingContainer.unbindFromParent()
+ workspace.rootTilingContainer.unbindIfBound()
restoreTreeRecursive(frozenContainer: frozenWorkspace.rootTilingNode, parent: workspace, index: INDEX_BIND_LAST)
for window in (orphans - workspace.rootTilingContainer.allLeafWindowsRecursive) {
window.relayoutWindow(on: workspace, forceTile: true)But it will fix only symptoms, not the root cause, because some invariants will still be broken |
|
The only case when That's why it's weird for me to hear that people observe the crash when they unplug the dock. I'm curious to know what window died and then restored its window ID (probably it some sort of synthetic window) and why the hell macOS do this? Or it all could be just a manifistation of another bug in AeroSpace. You can try to debug the following, if you observe the crash in cases other than lock/unlock the screen: diff --git a/Sources/AppBundle/tree/MacWindow.swift b/Sources/AppBundle/tree/MacWindow.swift
index 321fa2b..11a126e 100644
--- a/Sources/AppBundle/tree/MacWindow.swift
+++ b/Sources/AppBundle/tree/MacWindow.swift
@@ -63,7 +63,11 @@ final class MacWindow: Window, CustomStringConvertible {
// skipClosedWindowsCache is an optimization when it's definitely not necessary to cache closed window.
// If you are unsure, it's better to pass `false`
func garbageCollect(skipClosedWindowsCache: Bool) {
- if !skipClosedWindowsCache { cacheClosedWindowIfNeeded(window: self) }
+ if !skipClosedWindowsCache {
+ // The window will be recorded to closedWindowsCache, to potentially restore it from the cache if it turns out that the reason for closing the window is locking the screen
+ print("--- Window \(app.name) \(windowId) is about to die and will be recorded to closedWindowsCache.")
+ cacheClosedWindowIfNeeded(window: self)
+ }
if MacWindow.allWindowsMap.removeValue(forKey: windowId) == nil {
return
}
diff --git a/Sources/AppBundle/tree/frozen/closedWindowsCache.swift b/Sources/AppBundle/tree/frozen/closedWindowsCache.swift
index 1e9539f..8ab361d 100644
--- a/Sources/AppBundle/tree/frozen/closedWindowsCache.swift
+++ b/Sources/AppBundle/tree/frozen/closedWindowsCache.swift
@@ -50,6 +50,7 @@ func restoreClosedWindowsCacheIfNeeded(newlyDetectedWindow: Window) -> Bool {
if !closedWindowsCache.windowIds.contains(newlyDetectedWindow.windowId) {
return false
}
+ print("--- macOS decided to reuse window ID for this window: \(newlyDetectedWindow). Normally this should only happen when you lock/unlock the screen. It's your case, right, right?...")
let monitors = monitors
let topLeftCornerToMonitor = monitors.grouped { $0.rect.topLeftCorner }
|
|
Ok, I managed to compile the app with the modified code from both comments, and I ran it attached to the debugger. The attached file is the result of unplugging the dock. |
|
Edit: for sure I can reproduce the "reuse window ID" message with the Android emulator window, by minimizing it to the dock and reopening, or moving it between the different monitors. Doesn't work with other apps, though. |
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This was referenced Dec 4, 2024
Closed
|
fyi, I've been running the debug build since my last comment (i.e., ~5 days) and it only crashed just now after unlocking the screen. I have to say, nevertheless, that the crashlog is similar to my previous one (somewhat longer, though); furthermore, the window appearing in the "already unbound" line is ChatGPT once again. I can attach it, but I don't know if it will add any new information (and neither the print statements; as I had been running this for a long time, I'm not sure the exact moment that the lines start referring directly to the crash). Clearly, in any case, I'm not able to consistently reproduce the crash neither with lock/unlock nor with plugging/unplugging the dock. I'll go back to the production build. |
nikitabobko
added a commit
that referenced
this issue
Dec 5, 2024
This commit should _fix #771 Some functions in the crash stacktrace were inlined, but now I think the problematic call is `window.relayoutWindow`
nikitabobko
added a commit
that referenced
this issue
Dec 5, 2024
…window in the tree couldn't be restored Related: #771 Motivation: I am not aware of any test case that would lead to problems. The code change is purely for sanity
|
I didn't manage to reproduce the problem, but I have new theories.
So if somebody experience the crash in 0.16.2, I'm interested to see the crash log. Please note that 0.16.1 release is broken, and the crash happening in 0.16.1 is a different one. Update to 0.16.2 |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Thanks @nikitabobko - Would it be possible to update the brew casks to include 0.16.2? |
|
Given that I've not received new crash reports with 0.16.2-Beta, I optimistically assume that the problem is fixed. |
|
I am on 0.16.2-beta and I still see this issue. Happens 100% of the time after macos auto locks on idle. Crash Report |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I believe I was using a keyboard shortcut to move a window to another workspace, but I was pretty distracted
The text was updated successfully, but these errors were encountered: