This is the collective yearly thread for macOS betas. Please use this to discuss instead of opening new issues.
I will try to keep this updated just like every year.
2021-06-07 Developer Beta 1 (21A5248p)
Dock.app is available at [Dock.app.zip](https://github.com/koekeishiya/yabai/files/6617787/Dock.app.zip).
Issue
Note
build from source fails
Click to expand build log
```
❯ make
rm -rf ./bin
xcrun clang ./src/osax/loader.m -shared -O2 -mmacosx-version-min=10.13 -o ./src/osax/loader -framework Foundation
xcrun clang ./src/osax/payload.m -shared -fPIC -O2 -mmacosx-version-min=10.13 -o ./src/osax/payload -framework Foundation -framework Carbon
./src/osax/payload.m:37:8: error: unknown type name 'CGError'; did you mean 'NSError'?
extern CGError CGSGetConnectionPSN(int cid, ProcessSerialNumber *psn);
^~~~~~~
NSError
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here
@class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection;
^
./src/osax/payload.m:37:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'?
extern CGError CGSGetConnectionPSN(int cid, ProcessSerialNumber *psn);
^
*
./src/osax/payload.m:38:8: error: unknown type name 'CGError'; did you mean 'NSError'?
extern CGError CGSSetWindowAlpha(int cid, uint32_t wid, float alpha);
^~~~~~~
NSError
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here
@class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection;
^
./src/osax/payload.m:38:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'?
extern CGError CGSSetWindowAlpha(int cid, uint32_t wid, float alpha);
^
*
./src/osax/payload.m:39:8: error: unknown type name 'CGError'; did you mean 'NSError'?
extern CGError CGSSetWindowListAlpha(int cid, const uint32_t *window_list, int window_count, float alpha, float duration);
^~~~~~~
NSError
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here
@class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection;
^
./src/osax/payload.m:39:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'?
extern CGError CGSSetWindowListAlpha(int cid, const uint32_t *window_list, int window_count, float alpha, float duration);
^
*
./src/osax/payload.m:40:8: error: unknown type name 'CGError'; did you mean 'NSError'?
extern CGError CGSSetWindowLevel(int cid, uint32_t wid, int level);
^~~~~~~
NSError
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here
@class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection;
^
./src/osax/payload.m:40:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'?
extern CGError CGSSetWindowLevel(int cid, uint32_t wid, int level);
^
*
./src/osax/payload.m:42:8: error: unknown type name 'CGError'; did you mean 'NSError'?
extern CGError CGSReassociateWindowsSpacesByGeometry(int cid, CFArrayRef window_list);
^~~~~~~
NSError
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here
@class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection;
^
./src/osax/payload.m:42:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'?
extern CGError CGSReassociateWindowsSpacesByGeometry(int cid, CFArrayRef window_list);
^
*
./src/osax/payload.m:43:8: error: unknown type name 'CGError'; did you mean 'NSError'?
extern CGError CGSGetWindowOwner(int cid, uint32_t wid, int *window_cid);
^~~~~~~
NSError
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here
@class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection;
^
./src/osax/payload.m:43:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'?
extern CGError CGSGetWindowOwner(int cid, uint32_t wid, int *window_cid);
^
*
./src/osax/payload.m:44:8: error: unknown type name 'CGError'; did you mean 'NSError'?
extern CGError CGSInvalidateWindowShadow(int cid, CGWindowID wid);
^~~~~~~
NSError
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here
@class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection;
^
./src/osax/payload.m:44:51: error: unknown type name 'CGWindowID'
extern CGError CGSInvalidateWindowShadow(int cid, CGWindowID wid);
^
./src/osax/payload.m:44:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'?
extern CGError CGSInvalidateWindowShadow(int cid, CGWindowID wid);
^
*
./src/osax/payload.m:45:8: error: unknown type name 'CGError'; did you mean 'NSError'?
extern CGError CGSSetWindowTags(int cid, uint32_t wid, const int tags[2], size_t maxTagSize);
^~~~~~~
NSError
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here
@class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection;
^
./src/osax/payload.m:45:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'?
extern CGError CGSSetWindowTags(int cid, uint32_t wid, const int tags[2], size_t maxTagSize);
^
*
./src/osax/payload.m:46:8: error: unknown type name 'CGError'; did you mean 'NSError'?
extern CGError CGSClearWindowTags(int cid, uint32_t wid, const int tags[2], size_t maxTagSize);
^~~~~~~
NSError
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here
@class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection;
^
./src/osax/payload.m:46:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'?
extern CGError CGSClearWindowTags(int cid, uint32_t wid, const int tags[2], size_t maxTagSize);
^
*
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
make: *** [src/osax/sa_loader.c] Error 1
```
I'm trying to get lldb to debug with the source code but as I said I'm completely useless at debugging binaries. Anyone have a tip to get source code rather than assembler code in the lldb output?
it already is though.. that's what's so confusing to me. It's compiled with the right flags as far as i know, with -g and -O0, and lldb says that the .dSYM file is there, but doesn't show source code in the debugging output
It looks like something is causing an apple service to segfault that yabai is calling, which is why compiling with -g isn't changing anything. The segfault is caused in lib_objc not in the yabai codebase
Maybe @koekeishiya in some point of the future could write down how to find them. If more people would know how to find them, we would maybe get faster updates for yabai. Especially if @koekeishiya isn't always on the newest version.
For x86-64, in init_instances of src/osax/payload.m, altering the way the pointers are computed to use the following might work:
if (os_version.majorVersion == 12) {
uint64_t baseaddr = image_slide();
if (0x100000000ULL != static_base_address()) {
NSLog(@"[yabai-sa] payload offsets not compatible with OS version!");
return;
}
// globals
dock_spaces = [(*(id *)(baseaddr + 0x100434CB8ULL)) retain];
dp_desktop_picture_manager = [(*(id *)(baseaddr + 0x100434D38ULL)) retain];
// function pointers
add_space_fp = baseaddr + 0x10022F760ULL;
remove_space_fp = baseaddr + 0x1002E718AULL;
move_space_fp = baseaddr + 0x1002D7D2DULL;
set_front_window_fp = baseaddr + 0x100051E40ULL;
NSLog(@"[yabai-sa] payload offsets computed relative to %llx", baseaddr);
} else { // < 12.x...
// move old code here
}
As @vespakoen pointed out, the arm64 addresses are already in my fork, but from this thread, it looks like there are other issues that need to be addressed to get it to compile. Anyway, I can't test the above, but the addresses should be good at the very least, if someone is able to build on that.
With regards to finding the patterns/addresses going forward, for arm64, after manually finding them all for one version of Dock, I've been able to use diaphora to find them for future versions with relative ease. You can download the databases I've made for 12 beta 1 from here:
@xorpse I got yabai to compile and even inject the SA on beta 1. Everything seemed to work fine, even the SA stuff like space focus and PiP.
Until the WindowServer crashed completely.. I kept using it for a while but the WindowServer crashes every 10 minutes and I would need to relogin and reopen the windows everytime.
I suspect this is a bug in the current beta, I don't see how the SA could cause these kind of crashes.
We have to be a bit more patient 😅 things are expected to fail in a beta
@alin23 Nice :)! Yep, I'd imagine if the crashes are to do with the scripting additions, they would happen more or less instantly after one of the actions associated with the pointers we're using in Dock is triggered.
@xorpse is it possible to allow your fork to build on macOS 12 as well? Currently on my m1 machine it fails with the payload.m issue as well. Someone mentioned adding #include <CoreGraphics/CoreGraphics.h> to the /src/osax/payload.m should do the trick
@shaunsingh You'll have to build it directly from the repository (i.e., clone then run make -f makefile). The brew formula at xorpse/formulae/yabai builds yabai for arm64e rather than x86-64 (you can confirm via file $(which yabai)).
@shaunsingh Sorry I totally missed you were trying it on an M1... I don't plan on upgrading to 12 for the time being---so right now, I can't help more than I have already. I'd follow the advice that @alin23 gave and use the Frida injector instead of the bundled one.
@alin23 so the non-Frida injector doesn't work at all on 12? Do you happen to have any logs of the crashes?
I'm a total novice with C so I'm not much help on that end, but I'm running the public beta on an M1 MacBook Air and totally willing to do any testing if anyone needs it.
@alin23 so the non-Frida injector doesn't work at all on 12? Do you happen to have any logs of the crashes?
Okay, it seems like @alin23 and I were both neglecting (EDIT: or perhaps upgrading to beta 2 reverted it on them?) to follow all instructions, in particular those from
After fixing that boot-arg (and currently running full csrutil disable) and doing make install; mv ./bin/ybai /usr/local/bin/; yabai on xorpse@c91a32fc454a057e9aeeaf458ceba0cded7b0b75 (and granting Accessibility on iTerm), yabai is running steadily and managing windows successfully
I did get the
sudo yabai --install-sa and sudo yabai --load-sa both run and exit silently with error; install with 2, load with 1
EDIT: seems to not matter that I ran the injector actually ... After running install-sa and load-sa commands, on next launch of an app, yabai segfaults as
Idk if this implies that the payload was injected somewhere but is segfaulting, or just that yabai thinks its loaded and tries to talk to it but it isn't there
(I'm a little suprised its yabai and not e.g. Dock that goes down if the former)
as built above, it seems to run fine indefinitely so long as the apps running / drawing windows are the same (or a subset of) as when yabai was started (including minimizing, hiding, Cmd-Tab, and opening additional windows of applications that were started before yabai), but it segfaulsts as soon as you open a new application (including one you close while yabai is running)
(or in some cases, it seemed like it crashed when I only got as far as right clickin on an icon of an open app in the dock, but that seems not reliably reproducible)
or we can take the above crashdump at its word (KERN_INVALID_ADDRESS at 0x00201086d77fc190 -> 0x00001086d77fc190 (possible pointer authentication failure)) and assume this is a pointer authentication problem we have to deal with now that we've opted into the arm64e abi
lldb isn't letting me call into any fields on the variable but printing it (p *application) gives e.g.
this looks pretty ~uninitialized to my eye but I am not especially familiar with Objective C, so idk how much it normally is lazy about initializing state.
I look particularly though at _pid = 0 ; contrasted to the pid that is available as process->pid so I wonder if we just can/wanna ~ [[NSRunningApplication alloc] init: process->pid] if the process->ns_application pointer is off limits for whatever reason
Well, I'm not sure its the right way to handle it, but the above mentioning PRs ( xorpse#5 aka #967 ) do appear to fix my crashes – yabai now happily runs through and starts managing windows for newly opened applications
As xorpse and I were starting to discuss in the PR on that fork, w/ arm64e in general, some of this might go away if I / someone is notarizing/signing the binary, which right now my build isn't, and is running unsigned? or is trading on the notarization of the parent iTerm binary (or /bin/zsh? since /Applications/iTerm.app/Contents/MacOS/iTerm2 isn't compiled for arm64e anyway)
EDIT: though unlike the crash on start above, the report IS KERN_INVALID_ADDRESS but doesn't contain the explicit (possible pointer authentication failure) language - nor does it appear therein that it was a matter of pointer mutation (as I guess was the one before ... which is a little odd maybe) vs mere dereference, use after free
EDIT 2: I have quite low battery at the moment (like 5%; and gonna go plug in), and, in hindsight, this occurred right about the time the low battery notification was triggered. I wouldn't count that out as a proximate cause – if indeed (/ hopefully) this isn't trivial to re-trigger by just waiting later; EDIT 3: nope it has recurred a few times since (while charging, presumably just based on timing of GC sweeps?)
EDIT 4: but like ... its also run fine for quite a while, I've tested a few more features
Above PRs (xorpse#7 / #973) seem to maybe be more the root of the problem; so far it seems to also remove my GC-time crash from last comments (which ... kinda makes sense to me and kinda doesn't - I guess maybe that had to do with observers left referring to an already cleaned up object?)
while, as you can find in comments on the above PRs, this simple change may not be fully suitable to merge due to backwards-incompatibility (or rather possibly causing a memory leak in earlier and/or x86_64 versions of macOS), I can confirm that it seems to have eliminated all crashes I was experiencing (on M1 Monterey; and works built off xorpe's fork or here upstream)
As per (draft) PR https://github.com/xorpse/yabai/pull/8 - I have SA installing and "successfully" injecting to Dock on Monterey using the standalone injector.
The payload, however, reports back diminished capabilities (at least thats what I think its saying) ; and WindowServer crashes inside Skylight next time I [open, then close] an application - so I think maybe the hooks reporting success are not fully baked either
I tried my hand at improv' ing the RE; but after hours of staring at various disassemblies, I have some guesses but no confidence about what the targets we want are
seems to be working including SA (modulo quit-while-focused = lose-focus-then-hang issue below), with only pretty occasionally crashes of the yabai process
(with edgeless windows maybe? Xcode 13 certainly seemed to make it pretty angry) on M1 on Monterey dev Beta 3 (21A5294g) (and so one imagines maybe also public beta 2)
if you are gonna run sudo yabai --load-sa, you should probably like build from source yourself (which will also run the check that you are booted with -arm64e_preview_abi, which you need)
but if you wanna live dangerously, knock yourself out - here's the binary, unoptimized w/ debug symbols, signed by my dev cert, per ./scripts/codesign (zipped so GH will let me upload):
yabai.zip
TL;DR: (most) programs seem to hang if quit while focused if SA loaded & yabai running (EDIT: and `window_borders on` - see below )
WORKAROUND: use pkill or similar to exit programs, rather than depending on Cmd-Q or using Dock menu (or in many cases, closing last window)
---
Warning / new issue:
Since I got sa working*, when I tell an app started while yabai was running to Quit (not quite any app -- possibly any app which has a Dock icon?; also not some apps started before yabai / while yabai is stopped - even if yabai starts managing their windows later), they end hanging/"Not Responding" til Force Quit (by Option-RightClick > Force Quit, or Activity Monitor or kill -9). If any windows were open at quit time (if Quit by keyboard shortcut, menu item, etc), they go into pinwheel-nonresponsiveness, though can still be blurred or focused
running yabai w/ `debug_output on` indicates `yabai` also isn't running/receiving `EVENT_HANDLER_APPLICATION_TERMINATED` until that time either - so I kinda doubt the issue is in the `yabai`-process proper, is maybe in the sa payload or is maybe to do with yabai having registered observers?
stopping yabai does not allow exit to finish for applications which have already entered this state (which I would think it might if doing so caused yabai to vacate such observers)
*and going away for apps started while `yabai` is running if I restart `Dock` but don't reload the SA
EDIT: `killall Dock` to ~unload SA also does not, by itself, cleanup/finalize apps already having entered "quitting" state, though it does seem to allow them to be quit by [non-alt right click (or long-left-click)] > "Force Quit" in Dock (something that doesn't work while SA loaded - maybe is like `kill -1` vs `kill -9`, not sure?)
A bigger issue: ~windows that are "subrole":"AXDialog"~ an unclear subset of windows aren't getting drawn; they get an outline, but you can't see any content (just desktop background) except in in thumbnail in mission control and expose (if you first adjust opacity from 0);
stopping yabai and/or killing Dock does not get these windows to show. only restarting the owning application w/o yabai running (in some cases) gets it drawn
Edits of attempted ~blackbox debugging. TL;DR not clear what the issue is
---
I notice in `yabai -m query --windows` they are listed as "level: 0", whereas normal windows are at level: 20 so I wonder if perhaps they are being drawn ~under Finder / the desktop background. (or the other way, above the active plane of the screen?)
EDIT: Actually, now I'm seeing it happening for an "AXStandardWindow" subroled window (the `"AXDialog"`s were for minimized windows of the same app it turns out) - and actually all the windows (except a couple `"AXSystemDialog"`s) are level 0. so nix that; The MIA window was coming up opacity: 0, but doing `-m window --opacity 1` (or other values: 0.9, 0.8) doesn't fix it — (with `window_opacity on`) it changes how it draws in exposé, but not on the actual desktop
EDIT 2: none of the `--toggle` or `--layer`s of `-m window` directed at window seem to make a difference :( ; (other than toggle border, which toggles the border, but nothing else; and toggle `native-fullscreen` which just draws black (except again, visible in thumbnail in expose) )
I can't drag it or drop on it - so it seems like the view is MIA
EDIT 3: sending it to another space did "work", but resulted in it being drawn the same there; doing `--close` returned 0 and then error messages for further interactions with the id, but it left the window (empty outline) in place and caused subsequent `-m query --windows` to hang ; as well as other windows of app to become unresponsive until app force quit
:(
TL;DR The issue is mostly (not exclusively, but only reliably reproducibility for me) with Firefox windows requested from within browser (by ⌘ N, "Open Link in New Window", tridactlyl's :winopen) _after_ starting.
Workaround: doing open -n /Applications/Firefox\ Developer\ Edition.app opens additional working windows (somewhat surprisingly: without spawning additional `firefox` processes)
---
The above issue (window content not drawing outside expose), seemingly much like the hanging on quit issue:
- starts happening for previously working applications once both sa is loaded AND yabai started
- occurs for applications launched while (already) yabai was running and sa was loaded,
- continues after yabai stopped and/or Dock restarted (but application still running)
but its also only for some apps & windows w/o clear clustering:
- Specifically it DOES occurs for:
- standard windows (from Cmd-N, right click > Open Link In New Window, etc.) of Firefox (beyond windows opened on application start and/or prior to SA+yabai)
- the "Do you want to keep this new Document (Untitled)" dialog of Preview on trying to close an unsaved document (at least when it was the first thing I did after re-opening Preview; eventually I somehow got it to draw and then it has continued to)
- but It does NOT occur for:
- the downloads (Cmd J), browser console, etc of Firefox
- additional normal windows of Preview (via File > Open - though the dropdown in the open dialog seemed MIA)
- additional normal windows of iTerm, VSCode
---
EDIT: also whacky with Firefox, possibly of relevance, on (re)start windows seem ~undecided about what space they are in; "tiling" on the focused space (here, Desktop 1) while drawing in another space (here Desktop 3; until I focus that space and they resize over there):
so I wonder if somehow new windows are belonging to no space - being treated as minimized or something;
Also maybe the distinction here is whether (any) windows were restored on start vs opening fresh; (`open` ≠ `open -F` ). That would maybe explain why it was going down with Preview ... until it wasn't.
EDIT 2: Closing out all my old tabs, literally doing `open -F /Applications/Firefox\ Developer\ Edition.app` did not make any difference about non-drawing of a second window, though probably notably: if I close all windows, and then open a first one **by activating the program externally** (clicking on the icon in Dock, Cmd-Tab (with Contexts), `open $url`, etc) that works fine (but not if I right click on Dock > New Window, nor if I still have focus from closing last window and do Cmd-N)
EDIT 3: `open -n /Applications/Firefox\ Developer\ Edition.app` does work to open additional firefox windows which draw correctly; unlike doing, say, `open -n /Applications/iTerm.app`, this does not result in more than one instance of the app in the Dock, nor indeed more than one result to `pgrep firefox` – so ... I guess there is a different threading model here - or at least some capture/deduping?
EDIT 4: not that anyone was asking, but this all does not seem to depend on whether Firefox is my default browser (as it was for most of this, but making it not doesn't seem to change its behavior)
It also happens consistently with the confirm empty trash dialog. yabai -m rule --add app=Finder title='^$' manage=off did not seem to help.
Workaround: rm -rf ~/.Trash/* (or shred if you wanna be about that opsec-lyfe), or I guess use Path Finder
i recently upgraded to macos monterey developer beta and could not disable the sip(?). so yabai keeps giving me notifications about payload not being installed. I looked up how to disable sip. am unable to get into "Recovery Mode" as my mac mini doesn't seem to honour the keys pressed at boot (cmd + r or for that matter any other variations given here: https://support.apple.com/en-us/HT201255).
so i've currently removed yabai on macos 15. please let me know how i can fix this.
@sindhus-in in general, M1 macs have been switched to a press and hold down power button scheme leading to a boot loader screen where you select "options".
I do not have a Mac Mini, so I can't verify, but that's how it worked on my Air.
The article you linked to does at the top say "These key combinations apply only to Mac computers with an Intel processor, not Mac computers with Apple silicon."
TL;DR: (most) programs seem to hang if quit while focused if SA loaded & yabai running
after looking at some stacks, my guess is that this has to do with the (non)processing of Apple Events (with the AE* family of functions and/or NSAppleEventManager, and the related "System Events" automation permission) - that yabai (the process) needs to take additional proactive action in the processing thereof, and/or that the ScriptingAddition once injected is interfering with Dock's normal processing thereof.
Anyway, I am just noting this down while the thought is fresh; I will (hopefully find time/energy to) see if I can do something about it later
Well... I spent too much time looking elsewhere, but I am now pretty sure that the hang on quit bug is limited pretty strictly to configs with yabai -m config window_border on
and that in fact in most cases doing yabai -m config window_border off before attempting quit lets programs quit cleanly
(I thought I had tested this before and found it not to be the case. though ... I am working off
an active patch
```diff
diff --git a/src/event.c b/src/event.c
index 8998bf7..0c11dda 100644
--- a/src/event.c
+++ b/src/event.c
@@ -111,6 +111,10 @@ static EVENT_CALLBACK(EVENT_HANDLER_APPLICATION_LAUNCHED)
}
}
+ //we are done depending on workspace, and its better to clear the observers than let them fire again
+ //if, somehow, e.g. activation policy changes again
+ workspace_application_destroy_running_ns_application(g_workspace_context, process);
+
return EVENT_SUCCESS;
}
```
that limits potential side-effects of #973 , I spent most of the evening working under the theory that the observers registered in workspace_application_create_running_ns_application were part of the problem – and technically that could still be true; :sweat_smile: )
In any case, the issue seems to relate specifically to
(essentially the code that sticks the border to the window - so it moves with it and stays on top of it as its contents change. commenting out calls to scripting_addition_add_to_window_group but otherwise (visually dissatisfyingly) leaving borders on seems to eliminate issue)
I think the issue is possibly these window groups breaking [NSPersistentUIWindowSnapshotter captureAndWriteSnapshotForWindowNumber:forWindowID:waitUntilDone:] which I think is, these days, unfortunately on the path from a pretty vanilla [NSApplication -terminate] (via [NSPersistentUIManager flushPersistentStateAndClose] ?)
I am not sure whether yabaior the SA can insinuate itself early enough into the process to clear the way to avoid this conflict- I tried getting yabai notified on kEventAppQuit to no avail (I might have been doing something wrong, or AppKit just isn't reliably on Carbon anymore?);
Maybe acting on remote kAEQuitApplication will be more fruitful and sufficient
Parallels 17 released today added support for macOS Monterey guests/VMs on M1 - but as yet I have not cracked getting it into Recovery Mode to disable SIP on the guest / I am not sure its doable. Doing sudo nvram internet-recovery-mode=RecoveryModeDisk seemed to result in a normal/unchanged boot; doing sudo nvram internet-recovery-mode=RecoveryModeNetwork got me stuck in a black screen in the guest
I fear that the VM doesn't include the recovery partition and/but (EDIT: diskutil list suggests the recovery partition is allocated) that it doesn't initialize the frame buffer if netbooting.
I'mma give it another shot or two, but if anybody else cracks it, share please :-)
(Even with the PD17 macVM lacking snapshotting, etc as yet, ) I think it would be easier to deal with messing with the WindowServer et al when it doesn't crash my whole setup to do so
This is the collective yearly thread for macOS betas. Please use this to discuss instead of opening new issues.
I will try to keep this updated just like every year.
2021-06-07 Developer Beta 1 (21A5248p)
Dock.app is available at [Dock.app.zip](https://github.com/koekeishiya/yabai/files/6617787/Dock.app.zip).
Click to expand build log
``` ❯ make rm -rf ./bin xcrun clang ./src/osax/loader.m -shared -O2 -mmacosx-version-min=10.13 -o ./src/osax/loader -framework Foundation xcrun clang ./src/osax/payload.m -shared -fPIC -O2 -mmacosx-version-min=10.13 -o ./src/osax/payload -framework Foundation -framework Carbon ./src/osax/payload.m:37:8: error: unknown type name 'CGError'; did you mean 'NSError'? extern CGError CGSGetConnectionPSN(int cid, ProcessSerialNumber *psn); ^~~~~~~ NSError /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here @class NSAppleEventDescriptor, NSArrayAppreciate it, thank you
If you don't know about it, then you probably aren't using it.
then I doubt it. I was using firefox nightly by the way since at this point any bit of info would probably help
fixing the source code compiling would be the first step would it not? I'll see what I can find out
manually adding
#include <CoreGraphics/CoreGraphics.h>to the /src/osax/payload.m file gets source code to compilethis is a temp fix I assume, but its possible it could work just fine
still segfaults though
heres a quick lldb backtrace, although I'm totally useless after this point lol
https://github.com/shaunsingh/yabai/blob/0d2e49eebe7c1d6848e9ab5b32687a372e21cc6f/src/osax/payload.m#L193
Do lines referring to macOS 11 need to be updated to reference macOS 12 as well?
that still segfaults. good guess tho lol
I'm trying to get lldb to debug with the source code but as I said I'm completely useless at debugging binaries. Anyone have a tip to get source code rather than assembler code in the lldb output?
If you compile with -g set it should keep the file and line number of the error
it already is though.. that's what's so confusing to me. It's compiled with the right flags as far as i know, with -g and -O0, and lldb says that the .dSYM file is there, but doesn't show source code in the debugging output
It looks like something is causing an apple service to segfault that yabai is calling, which is why compiling with -g isn't changing anything. The segfault is caused in lib_objc not in the yabai codebase
Hey that's smart! I bet that's it. Does that then mean it's possible to trace the call back to the line of yabai code that caused the segfault?
Does xorpse's fork work?
It was made to support the M1 Apple computers, but seems to have updated references for Monterey, not sure if it runs on x86_64 though...
Just tried and no, xorpse's fork doesn't support MacOS 12 for x86
We need someone who knows how to update the patterns here https://github.com/shaunsingh/yabai/blob/0d2e49eebe7c1d6848e9ab5b32687a372e21cc6f/src/osax/x86_64/payload.m#L99 and the offsets.
Maybe @koekeishiya in some point of the future could write down how to find them. If more people would know how to find them, we would maybe get faster updates for yabai. Especially if @koekeishiya isn't always on the newest version.
For x86-64, in
init_instancesofsrc/osax/payload.m, altering the way the pointers are computed to use the following might work:As @vespakoen pointed out, the arm64 addresses are already in my fork, but from this thread, it looks like there are other issues that need to be addressed to get it to compile. Anyway, I can't test the above, but the addresses should be good at the very least, if someone is able to build on that.
With regards to finding the patterns/addresses going forward, for arm64, after manually finding them all for one version of Dock, I've been able to use diaphora to find them for future versions with relative ease. You can download the databases I've made for 12 beta 1 from here:
@xorpse I got yabai to compile and even inject the SA on beta 1. Everything seemed to work fine, even the SA stuff like space focus and PiP.
Until the WindowServer crashed completely.. I kept using it for a while but the WindowServer crashes every 10 minutes and I would need to relogin and reopen the windows everytime.
I suspect this is a bug in the current beta, I don't see how the SA could cause these kind of crashes.
We have to be a bit more patient 😅 things are expected to fail in a beta
@alin23 Nice :)! Yep, I'd imagine if the crashes are to do with the scripting additions, they would happen more or less instantly after one of the actions associated with the pointers we're using in Dock is triggered.
@xorpse is it possible to allow your fork to build on macOS 12 as well? Currently on my m1 machine it fails with the
payload.missue as well. Someone mentioned adding#include <CoreGraphics/CoreGraphics.h>to the /src/osax/payload.m should do the trick@shaunsingh I've pushed the addresses/offsets for x86-64 and header addition to my fork, see if it works for you.
@xorpse It installs now, but gives the following output if I try to start it
The same thing happens on zsh. I've signed the app and installed it via brew install xorpse/formulae/yabai --HEAD
@shaunsingh You'll have to build it directly from the repository (i.e., clone then run
make -f makefile). The brew formula atxorpse/formulae/yabaibuilds yabai for arm64e rather than x86-64 (you can confirm viafile $(which yabai)).In my case, I had to revert the following two commits and keep using frida to make it work on 12 beta 1:
https://github.com/xorpse/yabai/commit/3f0f1a6918bbf87fdf1c4084bdae76570f78b363
https://github.com/xorpse/yabai/commit/3354518fb5c11d1e4218786c2540a388bac94da0
@xorpse I have an m1 (aarch64) machine, should I still clone it manually?
@shaunsingh Sorry I totally missed you were trying it on an M1... I don't plan on upgrading to 12 for the time being---so right now, I can't help more than I have already. I'd follow the advice that @alin23 gave and use the Frida injector instead of the bundled one.
@alin23 so the non-Frida injector doesn't work at all on 12? Do you happen to have any logs of the crashes?
No logs and no debug info. The process is SIGKILLed instantly. Not even lldb can spawn it.
I suspect the PC register points to some non-executable code somehow, but I haven't looked into the injection code in detail.
I'm a total novice with C so I'm not much help on that end, but I'm running the public beta on an M1 MacBook Air and totally willing to do any testing if anyone needs it.
@xorpse :
Okay, it seems like @alin23 and I were both neglecting (EDIT: or perhaps upgrading to beta 2 reverted it on them?) to follow all instructions, in particular those from
https://github.com/xorpse/yabai/blob/c91a32fc454a057e9aeeaf458ceba0cded7b0b75/README-arm64.md?plain=1#L3-L14
I've added make-time guardrails for this in above mentioning PR ( xorpse/yabai#4 ).
For cleanliness/sanity, I've deleted my comments leading on to figuring this out from this issue and moved them into a comment on that PR
After fixing that boot-arg (and currently running full
csrutil disable) and doingmake install; mv ./bin/ybai /usr/local/bin/; yabaion xorpse@c91a32fc454a057e9aeeaf458ceba0cded7b0b75 (and granting Accessibility on iTerm), yabai is running steadily and managing windows successfullyI did get the
sudo yabai --install-saandsudo yabai --load-saboth run and exit silently with error;installwith2,loadwith1EDIT: seems to not matter that I ran the injector actually ...
After running, on next launch of an app,install-saandload-sacommandsyabaisegfaults asfull crash report
------------------------------------- Translated Report (Full Report Below) ------------------------------------- Process: yabai [2649] Path: /usr/local/bin/yabai Identifier: yabai Version: ??? Code Type: ARM-64 (Native) Parent Process: zsh [2204] Responsible: iTerm2 [2201] User ID: 501 Date/Time: 2021-07-22 22:10:51.5104 -0400 OS Version: macOS 12.0 (21A5284e) Report Version: 12 Anonymous UUID: 76D63C0B-357D-1700-5FC9-67A5DDB76A54 Time Awake Since Boot: 2100 seconds System Integrity Protection: disabled Crashed Thread: 1 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x00201086d77fc190 -> 0x00001086d77fc190 (possible pointer authentication failure) Exception Codes: 0x0000000000000001, 0x00201086d77fc190 Exception Note: EXC_CORPSE_NOTIFY Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11 Terminating Process: exc handler [2649] VM Region Info: 0x1086d77fc190 is not in any region. Bytes after previous region: 17690290798993 Bytes before following region: 87381789130352 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL commpage (reserved) 1000000000-7000000000 [384.0G] ---/--- SM=NUL ...(unallocated) ---> GAP OF 0x5f9000000000 BYTES MALLOC_NANO 600000000000-600008000000 [128.0M] rw-/rwx SM=PRV Application Specific Information: objc_msgSend() selector name: _fetchDynamicPropertiesIfNecessaryOrAppSeedIsOutOfDate Thread 0:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x1a82a75a8 __kdebug_trace64 + 8 1 CoreFoundation 0x1a83ab1ec __CFRunLoopDoBlocks + 104 2 CoreFoundation 0x1a83a9f98 __CFRunLoopRun + 800 3 CoreFoundation 0x1a83a94fc CFRunLoopRunSpecific + 600 4 CoreFoundation 0x1a84347d4 CFRunLoopRun + 64 5 yabai 0x104ff1bc0 main + 2024 6 dyld 0x1052810fc start + 520 Thread 1 Crashed: 0 libobjc.A.dylib 0x1a816ac80 objc_msgSend + 32 1 AppKit 0x1aaea6f40 -[NSRunningApplication activationPolicy] + 60 2 yabai 0x104ff2378 EVENT_HANDLER_APPLICATION_LAUNCHED + 204 3 yabai 0x104fd2e7c event_loop_run + 136 4 libsystem_pthread.dylib 0x1a82e043c _pthread_start + 148 5 libsystem_pthread.dylib 0x1a82db0d4 thread_start + 8 Thread 2: 0 libsystem_kernel.dylib 0x1a82acb58 __accept + 8 1 yabai 0x104fd0344 socket_connection_handler + 56 2 libsystem_pthread.dylib 0x1a82e043c _pthread_start + 148 3 libsystem_pthread.dylib 0x1a82db0d4 thread_start + 8 Thread 3: 0 libsystem_pthread.dylib 0x1a82db0c0 start_wqthread + 0 Thread 4: 0 libsystem_pthread.dylib 0x1a82db0c0 start_wqthread + 0 Thread 1 crashed with ARM Thread State (64-bit): x0: 0x000060000309c180 x1: 0x00000001f260c969 x2: 0x000000000000a713 x3: 0x0000000000000000 x4: 0x00000000000130a8 x5: 0x0000000000000000 x6: 0x4076600000000000 x7: 0x0000000000000000 x8: 0x00000001f260c000 x9: 0x5e32976c6d6b003d x10: 0x6ae160000309c180 x11: 0x007ffffffffffff8 x12: 0x0000000000000100 x13: 0x00001086d77fc180 x14: 0x0000000000000001 x15: 0x00201086d77fc180 x16: 0x00201086d77fc180 x17: 0x00000002026926a0 x18: 0x0000000000000000 x19: 0x000060000309c180 x20: 0x0000000000000000 x21: 0x0000000105000a68 x22: 0x000000010505e000 x23: 0x0000000105062000 x24: 0x0000000107da0640 x25: 0x0000000000000000 x26: 0x0000000000000000 x27: 0x0000000000000000 x28: 0x0000000000000000 fp: 0x000000016afd2eb0 lr: 0x00000001aaea6f40 sp: 0x000000016afd2e90 pc: 0x00000001a816ac80 cpsr: 0x20001000 far: 0x00201086d77fc190 esr: 0x92000004 (Data Abort) byte read Translation fault Binary Images: 0x1a82a3000 - 0x1a82d8fff libsystem_kernel.dylib (*) <32078db9-c918-3b93-9856-bd059bff1014> /usr/lib/system/libsystem_kernel.dylib 0x1a8327000 - 0x1a8841fff com.apple.CoreFoundation (6.9) <7469260a-0de6-3ef9-9916-b8405d9d4405> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x104fcc000 - 0x104ffffff yabai (*) /usr/local/bin/yabai
0x10527c000 - 0x1052d7fff dyld (*) <100198d7-325a-3466-9d9e-a4ae9b1af62a> /usr/lib/dyld
0x1a8165000 - 0x1a81a0fff libobjc.A.dylib (*) <826168ac-98e3-3eee-b1cc-40542102cd92> /usr/lib/libobjc.A.dylib
0x1aae68000 - 0x1abd04fff com.apple.AppKit (6.9) <095f5f48-68f3-3ba6-9e39-007ea0fe1346> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
0x1a82d9000 - 0x1a82e5fff libsystem_pthread.dylib (*) /usr/lib/system/libsystem_pthread.dylib
0x0 - 0xffffffffffffffff ??? (*) <00000000-0000-0000-0000-000000000000> ???
External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by all processes on this machine:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
VM Region Summary:
ReadOnly portion of Libraries: Total=755.8M resident=0K(0%) swapped_out_or_unallocated=755.8M(100%)
Writable regions: Total=722.9M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=722.9M(100%)
VIRTUAL REGION
REGION TYPE SIZE COUNT (non-coalesced)
=========== ======= =======
Activity Tracing 256K 1
ColorSync 384K 21
CoreGraphics 16K 1
Kernel Alloc Once 32K 1
MALLOC 208.2M 28
MALLOC guard page 96K 5
MALLOC_MEDIUM (reserved) 120.0M 1 reserved VM address space (unallocated)
MALLOC_NANO (reserved) 384.0M 1 reserved VM address space (unallocated)
STACK GUARD 56.1M 5
Stack 10.1M 5
VM_ALLOCATE 1.0G 9
__AUTH 1725K 147
__AUTH_CONST 9498K 293
__DATA 7986K 280
__DATA_CONST 9743K 294
__DATA_DIRTY 581K 101
__FONT_DATA 4K 1
__LINKEDIT 548.3M 4
__OBJC_CONST 1217K 121
__OBJC_RO 81.0M 1
__OBJC_RW 2992K 1
__TEXT 207.5M 309
__UNICODE 588K 1
dyld private memory 1024K 1
mapped file 50.7M 11
shared memory 880K 14
=========== ======= =======
TOTAL 2.7G 1657
TOTAL, minus reserved VM space 2.2G 1657
-----------
Full Report
-----------
{"app_name":"yabai","timestamp":"2021-07-22 22:10:52.00 -0400","app_version":"","slice_uuid":"a6686cf2-5892-310e-803e-0d902c1b94cb","build_version":"","platform":1,"share_with_app_devs":0,"is_first_party":1,"etl_key":"3","bug_type":"309","os_version":"macOS 12.0 (21A5284e)","incident_id":"2AAA9B07-26DE-4E42-900F-01E727CEBA39","name":"yabai"}
{
"uptime" : 2100,
"procLaunch" : "2021-07-22 22:10:29.3372 -0400",
"procRole" : "Non UI",
"version" : 2,
"userID" : 501,
"deployVersion" : 209,
"modelCode" : "MacBookAir10,1",
"procStartAbsTime" : 51720310700,
"coalitionID" : 955,
"osVersion" : {
"train" : "macOS 12.0",
"build" : "21A5284e",
"releaseType" : "User"
},
"captureTime" : "2021-07-22 22:10:51.5104 -0400",
"incident" : "2AAA9B07-26DE-4E42-900F-01E727CEBA39",
"pid" : 2649,
"procExitAbsTime" : 52252084179,
"translated" : false,
"cpuType" : "ARM-64",
"procName" : "yabai",
"procPath" : "\/usr\/local\/bin\/yabai",
"parentProc" : "zsh",
"parentPid" : 2204,
"coalitionName" : "com.googlecode.iterm2",
"crashReporterKey" : "76D63C0B-357D-1700-5FC9-67A5DDB76A54",
"responsiblePid" : 2201,
"responsibleProc" : "iTerm2",
"sip" : "disabled",
"vmRegionInfo" : "0x1086d77fc190 is not in any region. Bytes after previous region: 17690290798993 Bytes before following region: 87381789130352\n REGION TYPE START - END [ VSIZE] PRT\/MAX SHRMOD REGION DETAIL\n commpage (reserved) 1000000000-7000000000 [384.0G] ---\/--- SM=NUL ...(unallocated)\n---> GAP OF 0x5f9000000000 BYTES\n MALLOC_NANO 600000000000-600008000000 [128.0M] rw-\/rwx SM=PRV ",
"isCorpse" : 1,
"exception" : {"codes":"0x0000000000000001, 0x00201086d77fc190","rawCodes":[1,9025370581877136],"type":"EXC_BAD_ACCESS","signal":"SIGSEGV","subtype":"KERN_INVALID_ADDRESS at 0x00201086d77fc190 -> 0x00001086d77fc190 (possible pointer authentication failure)"},
"termination" : {"flags":0,"code":11,"namespace":"SIGNAL","indicator":"Segmentation fault: 11","byProc":"exc handler","byPid":2649},
"vmregioninfo" : "0x1086d77fc190 is not in any region. Bytes after previous region: 17690290798993 Bytes before following region: 87381789130352\n REGION TYPE START - END [ VSIZE] PRT\/MAX SHRMOD REGION DETAIL\n commpage (reserved) 1000000000-7000000000 [384.0G] ---\/--- SM=NUL ...(unallocated)\n---> GAP OF 0x5f9000000000 BYTES\n MALLOC_NANO 600000000000-600008000000 [128.0M] rw-\/rwx SM=PRV ",
"asi" : {"objc":["objc_msgSend() selector name: _fetchDynamicPropertiesIfNecessaryOrAppSeedIsOutOfDate"]},
"extMods" : {"caller":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"system":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"targeted":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"warnings":0},
"faultingThread" : 1,
"threads" : [{"id":39607,"queue":"com.apple.main-thread","frames":[{"imageOffset":17832,"symbol":"__kdebug_trace64","symbolLocation":8,"imageIndex":0},{"imageOffset":541164,"symbol":"__CFRunLoopDoBlocks","symbolLocation":104,"imageIndex":1},{"imageOffset":536472,"symbol":"__CFRunLoopRun","symbolLocation":800,"imageIndex":1},{"imageOffset":533756,"symbol":"CFRunLoopRunSpecific","symbolLocation":600,"imageIndex":1},{"imageOffset":1103828,"symbol":"CFRunLoopRun","symbolLocation":64,"imageIndex":1},{"imageOffset":154560,"symbol":"main","symbolLocation":2024,"imageIndex":2},{"imageOffset":20732,"symbol":"start","symbolLocation":520,"imageIndex":3}]},{"triggered":true,"id":39612,"threadState":{"x":[{"value":105553167237504},{"value":8361396585,"objc-selector":"_fetchDynamicPropertiesIfNecessaryOrAppSeedIsOutOfDate"},{"value":42771},{"value":0},{"value":77992},{"value":0},{"value":4645005618795511808},{"value":0},{"value":8361394176,"objc-selector":"estroyAllUnobservedSubsystems"},{"value":6787654080348749885},{"value":7701542390947496320},{"value":36028797018963960},{"value":256},{"value":18171327136128},{"value":1},{"value":9025370581877120},{"value":9025370581877120},{"value":8630380192},{"value":0},{"value":105553167237504},{"value":0},{"value":4378856040,"symbolLocation":0,"symbol":"event_handler"},{"value":4379238400,"symbolLocation":168216,"symbol":"__src_osax_payload"},{"value":4379254784,"symbolLocation":0,"symbol":"g_connection"},{"value":4426696256},{"value":0},{"value":0},{"value":0},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":7162457920},"cpsr":{"value":536875008},"fp":{"value":6089944752},"sp":{"value":6089944720},"esr":{"value":2449473540,"description":"(Data Abort) byte read Translation fault"},"pc":{"value":7115025536,"matchesCrashFrame":1},"far":{"value":9025370581877136}},"frames":[{"imageOffset":23680,"symbol":"objc_msgSend","symbolLocation":32,"imageIndex":4},{"imageOffset":257856,"symbol":"-[NSRunningApplication activationPolicy]","symbolLocation":60,"imageIndex":5},{"imageOffset":156536,"symbol":"EVENT_HANDLER_APPLICATION_LAUNCHED","symbolLocation":204,"imageIndex":2},{"imageOffset":28284,"symbol":"event_loop_run","symbolLocation":136,"imageIndex":2},{"imageOffset":29756,"symbol":"_pthread_start","symbolLocation":148,"imageIndex":6},{"imageOffset":8404,"symbol":"thread_start","symbolLocation":8,"imageIndex":6}]},{"id":39629,"frames":[{"imageOffset":39768,"symbol":"__accept","symbolLocation":8,"imageIndex":0},{"imageOffset":17220,"symbol":"socket_connection_handler","symbolLocation":56,"imageIndex":2},{"imageOffset":29756,"symbol":"_pthread_start","symbolLocation":148,"imageIndex":6},{"imageOffset":8404,"symbol":"thread_start","symbolLocation":8,"imageIndex":6}]},{"id":39835,"frames":[{"imageOffset":8384,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":6}]},{"id":39998,"frames":[{"imageOffset":8384,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":6}]}],
"usedImages" : [
{
"source" : "P",
"arch" : "arm64e",
"base" : 7116304384,
"size" : 221184,
"uuid" : "32078db9-c918-3b93-9856-bd059bff1014",
"path" : "\/usr\/lib\/system\/libsystem_kernel.dylib",
"name" : "libsystem_kernel.dylib"
},
{
"source" : "P",
"arch" : "arm64e",
"base" : 7116845056,
"CFBundleShortVersionString" : "6.9",
"CFBundleIdentifier" : "com.apple.CoreFoundation",
"size" : 5353472,
"uuid" : "7469260a-0de6-3ef9-9916-b8405d9d4405",
"path" : "\/System\/Library\/Frameworks\/CoreFoundation.framework\/Versions\/A\/CoreFoundation",
"name" : "CoreFoundation",
"CFBundleVersion" : "1842.100"
},
{
"source" : "P",
"arch" : "arm64e",
"base" : 4378640384,
"size" : 212992,
"uuid" : "a6686cf2-5892-310e-803e-0d902c1b94cb",
"path" : "\/usr\/local\/bin\/yabai",
"name" : "yabai"
},
{
"source" : "P",
"arch" : "arm64e",
"base" : 4381458432,
"size" : 376832,
"uuid" : "100198d7-325a-3466-9d9e-a4ae9b1af62a",
"path" : "\/usr\/lib\/dyld",
"name" : "dyld"
},
{
"source" : "P",
"arch" : "arm64e",
"base" : 7115001856,
"size" : 245760,
"uuid" : "826168ac-98e3-3eee-b1cc-40542102cd92",
"path" : "\/usr\/lib\/libobjc.A.dylib",
"name" : "libobjc.A.dylib"
},
{
"source" : "P",
"arch" : "arm64e",
"base" : 7162200064,
"CFBundleShortVersionString" : "6.9",
"CFBundleIdentifier" : "com.apple.AppKit",
"size" : 15323136,
"uuid" : "095f5f48-68f3-3ba6-9e39-007ea0fe1346",
"path" : "\/System\/Library\/Frameworks\/AppKit.framework\/Versions\/C\/AppKit",
"name" : "AppKit",
"CFBundleVersion" : "2087.14"
},
{
"source" : "P",
"arch" : "arm64e",
"base" : 7116525568,
"size" : 53248,
"uuid" : "b7109de1-8f64-3168-8631-be4ea5d37ea7",
"path" : "\/usr\/lib\/system\/libsystem_pthread.dylib",
"name" : "libsystem_pthread.dylib"
},
{
"size" : 0,
"source" : "A",
"base" : 0,
"uuid" : "00000000-0000-0000-0000-000000000000"
}
],
"vmSummary" : "ReadOnly portion of Libraries: Total=755.8M resident=0K(0%) swapped_out_or_unallocated=755.8M(100%)\nWritable regions: Total=722.9M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=722.9M(100%)\n\n VIRTUAL REGION \nREGION TYPE SIZE COUNT (non-coalesced) \n=========== ======= ======= \nActivity Tracing 256K 1 \nColorSync 384K 21 \nCoreGraphics 16K 1 \nKernel Alloc Once 32K 1 \nMALLOC 208.2M 28 \nMALLOC guard page 96K 5 \nMALLOC_MEDIUM (reserved) 120.0M 1 reserved VM address space (unallocated)\nMALLOC_NANO (reserved) 384.0M 1 reserved VM address space (unallocated)\nSTACK GUARD 56.1M 5 \nStack 10.1M 5 \nVM_ALLOCATE 1.0G 9 \n__AUTH 1725K 147 \n__AUTH_CONST 9498K 293 \n__DATA 7986K 280 \n__DATA_CONST 9743K 294 \n__DATA_DIRTY 581K 101 \n__FONT_DATA 4K 1 \n__LINKEDIT 548.3M 4 \n__OBJC_CONST 1217K 121 \n__OBJC_RO 81.0M 1 \n__OBJC_RW 2992K 1 \n__TEXT 207.5M 309 \n__UNICODE 588K 1 \ndyld private memory 1024K 1 \nmapped file 50.7M 11 \nshared memory 880K 14 \n=========== ======= ======= \nTOTAL 2.7G 1657 \nTOTAL, minus reserved VM space 2.2G 1657 \n",
"legacyInfo" : {
"threadTriggered" : {
}
},
"trialInfo" : {
"rollouts" : [
{
"rolloutId" : "607844aa04477260f58a8077",
"factorPackIds" : {
"SIRI_MORPHUN_ASSETS" : "60ef663fea07ad5dba6c903e"
},
"deploymentId" : 250000055
},
{
"rolloutId" : "602ad4dac86151000cf27e46",
"factorPackIds" : {
"SIRI_DICTATION_ASSETS" : "60f32ee7acdbc05299343789"
},
"deploymentId" : 250000131
},
{
"rolloutId" : "5fc94383418129005b4e9ae0",
"factorPackIds" : {
},
"deploymentId" : 250000096
},
{
"rolloutId" : "601d9415f79519000ccd4b69",
"factorPackIds" : {
"SIRI_TEXT_TO_SPEECH" : "60f6dfc2d2af457cffe62e0d"
},
"deploymentId" : 250000118
}
],
"experiments" : [
{
"treatmentId" : "e4f26a06-e220-41f9-8539-5302c9a13e15",
"experimentId" : "60d371a0ec19657d9a4419a7",
"deploymentId" : 500000003
}
]
}
}
Model: MacBookAir10,1, BootROM 7429.0.181.131.1, proc 8:4:4 processors, 16 GB, SMC
Graphics: kHW_AppleM1Item, Apple M1, spdisplays_builtin
Memory Module: LPDDR4
AirPort: spairport_wireless_card_type_wifi, wl0: Jun 21 2021 18:40:00 version 18.20.298.0.7.8.110 FWID 01-03951c1a
Bluetooth: Version (null), 0 services, 0 devices, 0 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
USB Device: USB 3.1 Bus
USB Device: USB 3.1 Bus
Thunderbolt Bus: MacBook Air, Apple Inc.
Thunderbolt Bus: MacBook Air, Apple Inc.
Idk if this implies that the payload was injected somewhere but is segfaulting, or just that yabai thinks its loaded and tries to talk to it but it isn't there(I'm a little suprised its yabai and not e.g. Dock that goes down if the former)We might still just be looking at #920 ;
as built above, it seems to run fine indefinitely so long as the apps running / drawing windows are the same (or a subset of) as when
yabaiwas started (including minimizing, hiding, Cmd-Tab, and opening additional windows of applications that were started beforeyabai), but it segfaulsts as soon as you open a new application (including one you close while yabai is running)(or in some cases, it seemed like it crashed when I only got as far as right clickin on an icon of an open app in the dock, but that seems not reliably reproducible)
Like @BeanieBen9990 in https://github.com/koekeishiya/yabai/issues/923#issuecomment-856901418 crash is coming from in
(not sure what if anything I'm doing differently to get line numbers / better symbols)
so seems like maybe https://github.com/koekeishiya/yabai/blob/8777db43b8551e0bc4e5c55d1e15bcbed52501a1/src/workspace.m#L86
is returning an uninitialized NSRunningApplication
or we can take the above crashdump at its word (
KERN_INVALID_ADDRESS at 0x00201086d77fc190 -> 0x00001086d77fc190 (possible pointer authentication failure)) and assume this is a pointer authentication problem we have to deal with now that we've opted into thearm64eabilldb isn't letting me call into any fields on the variable but printing it (
p *application) gives e.g.this looks pretty ~uninitialized to my eye but I am not especially familiar with Objective C, so idk how much it normally is lazy about initializing state.
I look particularly though at
_pid = 0; contrasted to the pid that is available asprocess->pidso I wonder if we just can/wanna ~[[NSRunningApplication alloc] init: process->pid]if theprocess->ns_applicationpointer is off limits for whatever reasonEDIT: I see that the above is all (in objective-C API vs ~swift with the init like I wrote) that thats what/all is happening here here https://github.com/koekeishiya/yabai/blob/8777db43b8551e0bc4e5c55d1e15bcbed52501a1/src/process_manager.c#L37
https://github.com/koekeishiya/yabai/blob/8777db43b8551e0bc4e5c55d1e15bcbed52501a1/src/workspace.m#L23-L26
so again I wonder whether its initialized too early now (or again just pointer auth ... stuff I don't understand yet)
Well, I'm not sure its the right way to handle it, but the above mentioning PRs ( xorpse#5 aka #967 ) do appear to fix my crashes – yabai now happily runs through and starts managing windows for newly opened applications
With this PR built in I do still eventually get another crash from inside
libobjc.A.dylibThere wasn't a particular thing I did / was doing when it crashed,
and honestly it looks to me like it was triggered by GC, which ... boo.
Maybe its on some yabai-centered callback / observer though; I didn't have a debugger attached.
That's reading past the interface though where its pointing as at least inside
CFRunLoopRun()(and in main thread / thread 0 at all)Crash report
------------------------------------- Translated Report (Full Report Below) ------------------------------------- Process: yabai [8733] Path: /usr/local/bin/yabai Identifier: yabai Version: ??? Code Type: ARM-64 (Native) Parent Process: zsh [8706] Responsible: iTerm2 [8703] User ID: 501 Date/Time: 2021-07-23 15:47:22.5161 -0400 OS Version: macOS 12.0 (21A5284e) Report Version: 12 Anonymous UUID: 76D63C0B-357D-1700-5FC9-67A5DDB76A54 Sleep/Wake UUID: 42AA0F11-9A22-46BC-BD6A-255AA777F513 Time Awake Since Boot: 10000 seconds Time Since Wake: 8499 seconds System Integrity Protection: disabled Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x00004f041bba0620 Exception Codes: 0x0000000000000001, 0x00004f041bba0620 Exception Note: EXC_CORPSE_NOTIFY Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11 Terminating Process: exc handler [8733] VM Region Info: 0x4f041bba0620 is not in any region. Bytes after previous region: 86398027302433 Bytes before following region: 18674052626912 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL commpage (reserved) 1000000000-7000000000 [384.0G] ---/--- SM=NUL ...(unallocated) ---> GAP OF 0x5f9000000000 BYTES MALLOC_NANO 600000000000-600008000000 [128.0M] rw-/rwx SM=PRV Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x19c375020 objc_release + 16 1 libobjc.A.dylib 0x19c379e5c AutoreleasePoolPage::releaseUntil(objc_object**) + 208 2 libobjc.A.dylib 0x19c376774 objc_autoreleasePoolPop + 244 3 CoreFoundation 0x19c5712d0 _CFAutoreleasePoolPop + 32 4 CoreFoundation 0x19c68a58c __CFRunLoopPerCalloutARPEnd + 48 5 CoreFoundation 0x19c5b3360 __CFRunLoopDoBlocks + 476 6 CoreFoundation 0x19c5b2338 __CFRunLoopRun + 1728 7 CoreFoundation 0x19c5b14fc CFRunLoopRunSpecific + 600 8 CoreFoundation 0x19c63c7d4 CFRunLoopRun + 64 9 yabai 0x100cb5ba8 main + 2024 10 dyld 0x1011310fc start + 520 Thread 1: 0 libsystem_kernel.dylib 0x19c4d8f68 sem_wait + 8 1 yabai 0x100c96e1c event_loop_run + 64 2 libsystem_pthread.dylib 0x19c4e843c _pthread_start + 148 3 libsystem_pthread.dylib 0x19c4e30d4 thread_start + 8 Thread 2: 0 libsystem_kernel.dylib 0x19c4b4b58 __accept + 8 1 yabai 0x100c9432c socket_connection_handler + 56 2 libsystem_pthread.dylib 0x19c4e843c _pthread_start + 148 3 libsystem_pthread.dylib 0x19c4e30d4 thread_start + 8 Thread 3: 0 libsystem_pthread.dylib 0x19c4e30c0 start_wqthread + 0 Thread 4: 0 libsystem_pthread.dylib 0x19c4e30c0 start_wqthread + 0 Thread 0 crashed with ARM Thread State (64-bit): x0: 0x0000600002a40600 x1: 0x000000014680d3b0 x2: 0x0000600003f680d0 x3: 0x00006000020480c0 x4: 0x0000000000000000 x5: 0x0000000000000011 x6: 0x0000000000000400 x7: 0x0000000000000000 x8: 0x00004f041bba0600 x9: 0x00004f041bba0600 x10: 0x000000014680d3b8 x11: 0x0000000000bf3d01 x12: 0x0000000152000028 x13: 0x00000000ffff8004 x14: 0x0000000000000000 x15: 0x000000000000e6e3 x16: 0x6c1180019c375010 x17: 0x00000001f669d120 x18: 0x0000000000000000 x19: 0x000000014680d000 x20: 0x000000014680d3b0 x21: 0x0000600002a40600 x22: 0x00000000a1a1a1a1 x23: 0xa3a3a3a3a3a3a3a3 x24: 0x0000000000000001 x25: 0x0000000000000000 x26: 0x000000014680d3b0 x27: 0x0000000000000000 x28: 0x00006000020480c0 fp: 0x000000016f16e460 lr: 0x000000019c379e5c sp: 0x000000016f16e430 pc: 0x000000019c375020 cpsr: 0x20000000 far: 0x00004f041bba0620 esr: 0x92000005 (Data Abort) byte read Translation fault Binary Images: 0x19c36d000 - 0x19c3a8fff libobjc.A.dylib (*) <826168ac-98e3-3eee-b1cc-40542102cd92> /usr/lib/libobjc.A.dylib 0x19c52f000 - 0x19ca49fff com.apple.CoreFoundation (6.9) <7469260a-0de6-3ef9-9916-b8405d9d4405> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x100c90000 - 0x100cc3fff yabai (*) /usr/local/bin/yabai
0x10112c000 - 0x101187fff dyld (*) <100198d7-325a-3466-9d9e-a4ae9b1af62a> /usr/lib/dyld
0x19c4ab000 - 0x19c4e0fff libsystem_kernel.dylib (*) <32078db9-c918-3b93-9856-bd059bff1014> /usr/lib/system/libsystem_kernel.dylib
0x19c4e1000 - 0x19c4edfff libsystem_pthread.dylib (*) /usr/lib/system/libsystem_pthread.dylib
0x0 - 0xffffffffffffffff ??? (*) <00000000-0000-0000-0000-000000000000> ???
External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by all processes on this machine:
task_for_pid: 16
thread_create: 1
thread_set_state: 294
VM Region Summary:
ReadOnly portion of Libraries: Total=755.8M resident=0K(0%) swapped_out_or_unallocated=755.8M(100%)
Writable regions: Total=725.0M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=725.0M(100%)
VIRTUAL REGION
REGION TYPE SIZE COUNT (non-coalesced)
=========== ======= =======
Activity Tracing 256K 1
ColorSync 384K 21
CoreGraphics 16K 1
Kernel Alloc Once 32K 1
MALLOC 208.2M 26
MALLOC guard page 96K 5
MALLOC_MEDIUM (reserved) 120.0M 1 reserved VM address space (unallocated)
MALLOC_NANO (reserved) 384.0M 1 reserved VM address space (unallocated)
STACK GUARD 56.1M 5
Stack 10.1M 5
VM_ALLOCATE 1.0G 31
__AUTH 1725K 147
__AUTH_CONST 9498K 293
__DATA 7986K 280
__DATA_CONST 9743K 294
__DATA_DIRTY 581K 101
__FONT_DATA 4K 1
__LINKEDIT 548.3M 4
__OBJC_CONST 1217K 121
__OBJC_RO 81.0M 1
__OBJC_RW 2992K 1
__TEXT 207.5M 309
__UNICODE 588K 1
dyld private memory 1024K 1
mapped file 53.2M 11
shared memory 880K 14
=========== ======= =======
TOTAL 2.7G 1677
TOTAL, minus reserved VM space 2.2G 1677
-----------
Full Report
-----------
{"app_name":"yabai","timestamp":"2021-07-23 15:47:22.00 -0400","app_version":"","slice_uuid":"baa5e31d-00b6-3a90-81aa-b21daed3daa3","build_version":"","platform":1,"share_with_app_devs":0,"is_first_party":1,"etl_key":"3","bug_type":"309","os_version":"macOS 12.0 (21A5284e)","incident_id":"71C3AD2D-263C-4D55-95BD-1E111CAB3B33","name":"yabai"}
{
"uptime" : 10000,
"procLaunch" : "2021-07-23 15:41:20.6291 -0400",
"procRole" : "Non UI",
"version" : 2,
"userID" : 501,
"deployVersion" : 209,
"modelCode" : "MacBookAir10,1",
"procStartAbsTime" : 243562836543,
"coalitionID" : 1086,
"osVersion" : {
"train" : "macOS 12.0",
"build" : "21A5284e",
"releaseType" : "User"
},
"captureTime" : "2021-07-23 15:47:22.5161 -0400",
"incident" : "71C3AD2D-263C-4D55-95BD-1E111CAB3B33",
"pid" : 8733,
"procExitAbsTime" : 252247925249,
"translated" : false,
"cpuType" : "ARM-64",
"procName" : "yabai",
"procPath" : "\/usr\/local\/bin\/yabai",
"parentProc" : "zsh",
"parentPid" : 8706,
"coalitionName" : "com.googlecode.iterm2",
"crashReporterKey" : "76D63C0B-357D-1700-5FC9-67A5DDB76A54",
"responsiblePid" : 8703,
"responsibleProc" : "iTerm2",
"wakeTime" : 8499,
"sleepWakeUUID" : "42AA0F11-9A22-46BC-BD6A-255AA777F513",
"sip" : "disabled",
"vmRegionInfo" : "0x4f041bba0620 is not in any region. Bytes after previous region: 86398027302433 Bytes before following region: 18674052626912\n REGION TYPE START - END [ VSIZE] PRT\/MAX SHRMOD REGION DETAIL\n commpage (reserved) 1000000000-7000000000 [384.0G] ---\/--- SM=NUL ...(unallocated)\n---> GAP OF 0x5f9000000000 BYTES\n MALLOC_NANO 600000000000-600008000000 [128.0M] rw-\/rwx SM=PRV ",
"isCorpse" : 1,
"exception" : {"codes":"0x0000000000000001, 0x00004f041bba0620","rawCodes":[1,86879063639584],"type":"EXC_BAD_ACCESS","signal":"SIGSEGV","subtype":"KERN_INVALID_ADDRESS at 0x00004f041bba0620"},
"termination" : {"flags":0,"code":11,"namespace":"SIGNAL","indicator":"Segmentation fault: 11","byProc":"exc handler","byPid":8733},
"vmregioninfo" : "0x4f041bba0620 is not in any region. Bytes after previous region: 86398027302433 Bytes before following region: 18674052626912\n REGION TYPE START - END [ VSIZE] PRT\/MAX SHRMOD REGION DETAIL\n commpage (reserved) 1000000000-7000000000 [384.0G] ---\/--- SM=NUL ...(unallocated)\n---> GAP OF 0x5f9000000000 BYTES\n MALLOC_NANO 600000000000-600008000000 [128.0M] rw-\/rwx SM=PRV ",
"extMods" : {"caller":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"system":{"thread_create":1,"thread_set_state":294,"task_for_pid":16},"targeted":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"warnings":0},
"faultingThread" : 0,
"threads" : [{"triggered":true,"id":188103,"threadState":{"x":[{"value":105553160570368},{"value":5477815216},{"value":105553182752976},{"value":105553150116032},{"value":0},{"value":17},{"value":1024},{"value":0},{"value":86879063639552},{"value":86879063639552},{"value":5477815224},{"value":12532993},{"value":5670699048},{"value":4294934532},{"value":0},{"value":59107},{"value":7787145975104491536,"symbolLocation":7787145968188653568,"symbol":"objc_release"},{"value":8429097248},{"value":0},{"value":5477814272},{"value":5477815216},{"value":105553160570368},{"value":2711724449},{"value":11791448172606497699},{"value":1},{"value":0},{"value":5477815216},{"value":0},{"value":105553150116032}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6915858012},"cpsr":{"value":536870912},"fp":{"value":6158738528},"sp":{"value":6158738480},"esr":{"value":2449473541,"description":"(Data Abort) byte read Translation fault"},"pc":{"value":6915837984,"matchesCrashFrame":1},"far":{"value":86879063639584}},"queue":"com.apple.main-thread","frames":[{"imageOffset":32800,"symbol":"objc_release","symbolLocation":16,"imageIndex":0},{"imageOffset":52828,"symbol":"AutoreleasePoolPage::releaseUntil(objc_object**)","symbolLocation":208,"imageIndex":0},{"imageOffset":38772,"symbol":"objc_autoreleasePoolPop","symbolLocation":244,"imageIndex":0},{"imageOffset":271056,"symbol":"_CFAutoreleasePoolPop","symbolLocation":32,"imageIndex":1},{"imageOffset":1422732,"symbol":"__CFRunLoopPerCalloutARPEnd","symbolLocation":48,"imageIndex":1},{"imageOffset":541536,"symbol":"__CFRunLoopDoBlocks","symbolLocation":476,"imageIndex":1},{"imageOffset":537400,"symbol":"__CFRunLoopRun","symbolLocation":1728,"imageIndex":1},{"imageOffset":533756,"symbol":"CFRunLoopRunSpecific","symbolLocation":600,"imageIndex":1},{"imageOffset":1103828,"symbol":"CFRunLoopRun","symbolLocation":64,"imageIndex":1},{"imageOffset":154536,"symbol":"main","symbolLocation":2024,"imageIndex":2},{"imageOffset":20732,"symbol":"start","symbolLocation":520,"imageIndex":3}]},{"id":188106,"frames":[{"imageOffset":188264,"symbol":"sem_wait","symbolLocation":8,"imageIndex":4},{"imageOffset":28188,"symbol":"event_loop_run","symbolLocation":64,"imageIndex":2},{"imageOffset":29756,"symbol":"_pthread_start","symbolLocation":148,"imageIndex":5},{"imageOffset":8404,"symbol":"thread_start","symbolLocation":8,"imageIndex":5}]},{"id":188112,"frames":[{"imageOffset":39768,"symbol":"__accept","symbolLocation":8,"imageIndex":4},{"imageOffset":17196,"symbol":"socket_connection_handler","symbolLocation":56,"imageIndex":2},{"imageOffset":29756,"symbol":"_pthread_start","symbolLocation":148,"imageIndex":5},{"imageOffset":8404,"symbol":"thread_start","symbolLocation":8,"imageIndex":5}]},{"id":191965,"frames":[{"imageOffset":8384,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":5}]},{"id":192181,"frames":[{"imageOffset":8384,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":5}]}],
"usedImages" : [
{
"source" : "P",
"arch" : "arm64e",
"base" : 6915805184,
"size" : 245760,
"uuid" : "826168ac-98e3-3eee-b1cc-40542102cd92",
"path" : "\/usr\/lib\/libobjc.A.dylib",
"name" : "libobjc.A.dylib"
},
{
"source" : "P",
"arch" : "arm64e",
"base" : 6917648384,
"CFBundleShortVersionString" : "6.9",
"CFBundleIdentifier" : "com.apple.CoreFoundation",
"size" : 5353472,
"uuid" : "7469260a-0de6-3ef9-9916-b8405d9d4405",
"path" : "\/System\/Library\/Frameworks\/CoreFoundation.framework\/Versions\/A\/CoreFoundation",
"name" : "CoreFoundation",
"CFBundleVersion" : "1842.100"
},
{
"source" : "P",
"arch" : "arm64e",
"base" : 4308140032,
"size" : 212992,
"uuid" : "baa5e31d-00b6-3a90-81aa-b21daed3daa3",
"path" : "\/usr\/local\/bin\/yabai",
"name" : "yabai"
},
{
"source" : "P",
"arch" : "arm64e",
"base" : 4312973312,
"size" : 376832,
"uuid" : "100198d7-325a-3466-9d9e-a4ae9b1af62a",
"path" : "\/usr\/lib\/dyld",
"name" : "dyld"
},
{
"source" : "P",
"arch" : "arm64e",
"base" : 6917107712,
"size" : 221184,
"uuid" : "32078db9-c918-3b93-9856-bd059bff1014",
"path" : "\/usr\/lib\/system\/libsystem_kernel.dylib",
"name" : "libsystem_kernel.dylib"
},
{
"source" : "P",
"arch" : "arm64e",
"base" : 6917328896,
"size" : 53248,
"uuid" : "b7109de1-8f64-3168-8631-be4ea5d37ea7",
"path" : "\/usr\/lib\/system\/libsystem_pthread.dylib",
"name" : "libsystem_pthread.dylib"
},
{
"size" : 0,
"source" : "A",
"base" : 0,
"uuid" : "00000000-0000-0000-0000-000000000000"
}
],
"vmSummary" : "ReadOnly portion of Libraries: Total=755.8M resident=0K(0%) swapped_out_or_unallocated=755.8M(100%)\nWritable regions: Total=725.0M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=725.0M(100%)\n\n VIRTUAL REGION \nREGION TYPE SIZE COUNT (non-coalesced) \n=========== ======= ======= \nActivity Tracing 256K 1 \nColorSync 384K 21 \nCoreGraphics 16K 1 \nKernel Alloc Once 32K 1 \nMALLOC 208.2M 26 \nMALLOC guard page 96K 5 \nMALLOC_MEDIUM (reserved) 120.0M 1 reserved VM address space (unallocated)\nMALLOC_NANO (reserved) 384.0M 1 reserved VM address space (unallocated)\nSTACK GUARD 56.1M 5 \nStack 10.1M 5 \nVM_ALLOCATE 1.0G 31 \n__AUTH 1725K 147 \n__AUTH_CONST 9498K 293 \n__DATA 7986K 280 \n__DATA_CONST 9743K 294 \n__DATA_DIRTY 581K 101 \n__FONT_DATA 4K 1 \n__LINKEDIT 548.3M 4 \n__OBJC_CONST 1217K 121 \n__OBJC_RO 81.0M 1 \n__OBJC_RW 2992K 1 \n__TEXT 207.5M 309 \n__UNICODE 588K 1 \ndyld private memory 1024K 1 \nmapped file 53.2M 11 \nshared memory 880K 14 \n=========== ======= ======= \nTOTAL 2.7G 1677 \nTOTAL, minus reserved VM space 2.2G 1677 \n",
"legacyInfo" : {
"threadTriggered" : {
"queue" : "com.apple.main-thread"
}
},
"trialInfo" : {
"rollouts" : [
{
"rolloutId" : "607844aa04477260f58a8077",
"factorPackIds" : {
"SIRI_MORPHUN_ASSETS" : "60ef663fea07ad5dba6c903e"
},
"deploymentId" : 250000055
},
{
"rolloutId" : "602ad4dac86151000cf27e46",
"factorPackIds" : {
"SIRI_DICTATION_ASSETS" : "60f32ee7acdbc05299343789"
},
"deploymentId" : 250000131
},
{
"rolloutId" : "5fc94383418129005b4e9ae0",
"factorPackIds" : {
},
"deploymentId" : 250000096
},
{
"rolloutId" : "601d9415f79519000ccd4b69",
"factorPackIds" : {
"SIRI_TEXT_TO_SPEECH" : "60f6dfc2d2af457cffe62e0d"
},
"deploymentId" : 250000118
}
],
"experiments" : [
{
"treatmentId" : "e4f26a06-e220-41f9-8539-5302c9a13e15",
"experimentId" : "60d371a0ec19657d9a4419a7",
"deploymentId" : 500000003
}
]
}
}
Model: MacBookAir10,1, BootROM 7429.0.181.131.1, proc 8:4:4 processors, 16 GB, SMC
Graphics: kHW_AppleM1Item, Apple M1, spdisplays_builtin
Memory Module: LPDDR4
AirPort: spairport_wireless_card_type_wifi, wl0: Jun 21 2021 18:40:00 version 18.20.298.0.7.8.110 FWID 01-03951c1a
Bluetooth: Version (null), 0 services, 0 devices, 0 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
USB Device: USB 3.1 Bus
USB Device: USB 3.1 Bus
Thunderbolt Bus: MacBook Air, Apple Inc.
Thunderbolt Bus: MacBook Air, Apple Inc.
As xorpse and I were starting to discuss in the PR on that fork, w/ arm64e in general, some of this might go away if I / someone is notarizing/signing the binary, which right now my build isn't, and is running unsigned? or is trading on the notarization of the parent iTerm binary (or
/bin/zsh? since/Applications/iTerm.app/Contents/MacOS/iTerm2isn't compiled forarm64eanyway)EDIT: though unlike the crash on start above, the report IS
KERN_INVALID_ADDRESSbut doesn't contain the explicit(possible pointer authentication failure)language - nor does it appear therein that it was a matter of pointer mutation (as I guess was the one before ... which is a little odd maybe) vs mere dereference, use after freeEDIT 2: I have quite low battery at the moment (like 5%; and gonna go plug in), and, in hindsight, this occurred right about the time the low battery notification was triggered. I wouldn't count that out as a proximate cause – if indeed (/ hopefully) this isn't trivial to re-trigger by just waiting later; EDIT 3: nope it has recurred a few times since (while charging, presumably just based on timing of GC sweeps?) EDIT 4: but like ... its also run fine for quite a while, I've tested a few more features
Above PRs (xorpse#7 / #973) seem to maybe be more the root of the problem; so far it seems to also remove my GC-time crash from last comments (which ... kinda makes sense to me and kinda doesn't - I guess maybe that had to do with observers left referring to an already cleaned up object?)
while, as you can find in comments on the above PRs, this simple change may not be fully suitable to merge due to backwards-incompatibility (or rather possibly causing a memory leak in earlier and/or x86_64 versions of macOS), I can confirm that it seems to have eliminated all crashes I was experiencing (on M1 Monterey; and works built off xorpe's fork or here upstream)
As per (draft) PR https://github.com/xorpse/yabai/pull/8 - I have SA installing and "successfully" injecting to Dock on Monterey using the standalone injector.
The payload, however, reports back diminished capabilities (at least thats what I think its saying) ; and WindowServer crashes inside Skylight next time I [open, then close] an application - so I think maybe the hooks reporting success are not fully baked either
https://github.com/xorpse/yabai/pull/8#issuecomment-889624767 :
I tried my hand at improv' ing the RE; but after hours of staring at various disassemblies, I have some guesses but no confidence about what the targets we want are
https://github.com/donaldguy/yabai/commit/77e8aad4c236400145a0eddb682c8a903d068e79 (See: https://github.com/xorpse/yabai/compare/master...donaldguy:77e8aad4c236400145a0eddb682c8a903d068e79 - my commits are linearized, but have link to relevant PRs in commit messages )
seems to be working including SA (modulo quit-while-focused = lose-focus-then-hang issue below), with only pretty occasionally crashes of the
yabaiprocess (with edgeless windows maybe? Xcode 13 certainly seemed to make it pretty angry) on M1 on Monterey dev Beta 3 (21A5294g) (and so one imagines maybe also public beta 2)if you are gonna run
sudo yabai --load-sa, you should probably like build from source yourself (which will also run the check that you are booted with-arm64e_preview_abi, which you need)but if you wanna live dangerously, knock yourself out - here's the binary, unoptimized w/ debug symbols, signed by my dev cert, per
./scripts/codesign(zipped so GH will let me upload): yabai.zipLAST UPDATED: Tue Aug 3 18:28:58 EDT 2021
TL;DR: (most) programs seem to hang if quit while focused if SA loaded & yabai running (EDIT: and `window_borders on` - see below )
--- Warning / new issue: Since I got sa working*, when I tell an app started while yabai was running to Quit (not quite any app -- possibly any app which has a Dock icon?; also not some apps started before yabai / while yabai is stopped - even if yabai starts managing their windows later), they end hanging/"Not Responding" til Force Quit (by Option-RightClick > Force Quit, or Activity Monitor or kill -9). If any windows were open at quit time (if Quit by keyboard shortcut, menu item, etc), they go into pinwheel-nonresponsiveness, though can still be blurred or focused running yabai w/ `debug_output on` indicates `yabai` also isn't running/receiving `EVENT_HANDLER_APPLICATION_TERMINATED` until that time either - so I kinda doubt the issue is in the `yabai`-process proper, is maybe in the sa payload or is maybe to do with yabai having registered observers? stopping yabai does not allow exit to finish for applications which have already entered this state (which I would think it might if doing so caused yabai to vacate such observers) *and going away for apps started while `yabai` is running if I restart `Dock` but don't reload the SA EDIT: `killall Dock` to ~unload SA also does not, by itself, cleanup/finalize apps already having entered "quitting" state, though it does seem to allow them to be quit by [non-alt right click (or long-left-click)] > "Force Quit" in Dock (something that doesn't work while SA loaded - maybe is like `kill -1` vs `kill -9`, not sure?)WORKAROUND: use pkill or similar to exit programs, rather than depending on Cmd-Q or using Dock menu (or in many cases, closing last window)
A bigger issue: ~windows that are
"subrole":"AXDialog"~ an unclear subset of windows aren't getting drawn; they get an outline, but you can't see any content (just desktop background) except in in thumbnail in mission control and expose (if you first adjust opacity from 0);stopping yabai and/or killing Dock does not get these windows to show. only restarting the owning application w/o yabai running (in some cases) gets it drawn
Edits of attempted ~blackbox debugging. TL;DR not clear what the issue is
--- I notice in `yabai -m query --windows` they are listed as "level: 0", whereas normal windows are at level: 20 so I wonder if perhaps they are being drawn ~under Finder / the desktop background. (or the other way, above the active plane of the screen?) EDIT: Actually, now I'm seeing it happening for an "AXStandardWindow" subroled window (the `"AXDialog"`s were for minimized windows of the same app it turns out) - and actually all the windows (except a couple `"AXSystemDialog"`s) are level 0. so nix that; The MIA window was coming up opacity: 0, but doing `-m window --opacity 1` (or other values: 0.9, 0.8) doesn't fix it — (with `window_opacity on`) it changes how it draws in exposé, but not on the actual desktop EDIT 2: none of the `--toggle` or `--layer`s of `-m window` directed at window seem to make a difference :( ; (other than toggle border, which toggles the border, but nothing else; and toggle `native-fullscreen` which just draws black (except again, visible in thumbnail in expose) ) I can't drag it or drop on it - so it seems like the view is MIA EDIT 3: sending it to another space did "work", but resulted in it being drawn the same there; doing `--close` returned 0 and then error messages for further interactions with the id, but it left the window (empty outline) in place and caused subsequent `-m query --windows` to hang ; as well as other windows of app to become unresponsive until app force quit :(TL;DR The issue is mostly (not exclusively, but only reliably reproducibility for me) with Firefox windows requested from within browser (by ⌘ N, "Open Link in New Window", tridactlyl's :winopen) _after_ starting.
--- The above issue (window content not drawing outside expose), seemingly much like the hanging on quit issue: - starts happening for previously working applications once both sa is loaded AND yabai started - occurs for applications launched while (already) yabai was running and sa was loaded, - continues after yabai stopped and/or Dock restarted (but application still running) but its also only for some apps & windows w/o clear clustering: - Specifically it DOES occurs for: - standard windows (from Cmd-N, right click > Open Link In New Window, etc.) of Firefox (beyond windows opened on application start and/or prior to SA+yabai) - the "Do you want to keep this new Document (Untitled)" dialog of Preview on trying to close an unsaved document (at least when it was the first thing I did after re-opening Preview; eventually I somehow got it to draw and then it has continued to) - but It does NOT occur for: - the downloads (Cmd J), browser console, etc of Firefox - additional normal windows of Preview (via File > Open - though the dropdown in the open dialog seemed MIA) - additional normal windows of iTerm, VSCode --- EDIT: also whacky with Firefox, possibly of relevance, on (re)start windows seem ~undecided about what space they are in; "tiling" on the focused space (here, Desktop 1) while drawing in another space (here Desktop 3; until I focus that space and they resize over there):  so I wonder if somehow new windows are belonging to no space - being treated as minimized or something; Also maybe the distinction here is whether (any) windows were restored on start vs opening fresh; (`open` ≠ `open -F` ). That would maybe explain why it was going down with Preview ... until it wasn't. EDIT 2: Closing out all my old tabs, literally doing `open -F /Applications/Firefox\ Developer\ Edition.app` did not make any difference about non-drawing of a second window, though probably notably: if I close all windows, and then open a first one **by activating the program externally** (clicking on the icon in Dock, Cmd-Tab (with Contexts), `open $url`, etc) that works fine (but not if I right click on Dock > New Window, nor if I still have focus from closing last window and do Cmd-N) EDIT 3: `open -n /Applications/Firefox\ Developer\ Edition.app` does work to open additional firefox windows which draw correctly; unlike doing, say, `open -n /Applications/iTerm.app`, this does not result in more than one instance of the app in the Dock, nor indeed more than one result to `pgrep firefox` – so ... I guess there is a different threading model here - or at least some capture/deduping? EDIT 4: not that anyone was asking, but this all does not seem to depend on whether Firefox is my default browser (as it was for most of this, but making it not doesn't seem to change its behavior)Workaround: doing open -n /Applications/Firefox\ Developer\ Edition.app opens additional working windows (somewhat surprisingly: without spawning additional `firefox` processes)
It also happens consistently with the confirm empty trash dialog.
yabai -m rule --add app=Finder title='^$' manage=offdid not seem to help.Workaround:
rm -rf ~/.Trash/*(orshredif you wanna be about that opsec-lyfe), or I guess use Path Finder(posting again from #925 as asked)
i recently upgraded to macos monterey developer beta and could not disable the sip(?). so yabai keeps giving me notifications about payload not being installed. I looked up how to disable sip. am unable to get into "Recovery Mode" as my mac mini doesn't seem to honour the keys pressed at boot (cmd + r or for that matter any other variations given here: https://support.apple.com/en-us/HT201255).
so i've currently removed yabai on macos 15. please let me know how i can fix this.
@sindhus-in in general, M1 macs have been switched to a press and hold down power button scheme leading to a boot loader screen where you select "options".
I do not have a Mac Mini, so I can't verify, but that's how it worked on my Air.
The article you linked to does at the top say "These key combinations apply only to Mac computers with an Intel processor, not Mac computers with Apple silicon."
The FAQ entry for the Mac mini M1 about reinstalling macOS leads to this article: https://support.apple.com/en-us/HT204904
Of above
after looking at some stacks, my guess is that this has to do with the (non)processing of Apple Events (with the AE* family of functions and/or NSAppleEventManager, and the related "System Events" automation permission) - that
yabai(the process) needs to take additional proactive action in the processing thereof, and/or that the ScriptingAddition once injected is interfering with Dock's normal processing thereof.Anyway, I am just noting this down while the thought is fresh; I will (hopefully find time/energy to) see if I can do something about it later
Well... I spent too much time looking elsewhere, but I am now pretty sure that the hang on quit bug is limited pretty strictly to configs with
yabai -m config window_border onand that in fact in most cases doingyabai -m config window_border offbefore attempting quit lets programs quit cleanly(I thought I had tested this before and found it not to be the case. though ... I am working off
an active patch
```diff diff --git a/src/event.c b/src/event.c index 8998bf7..0c11dda 100644 --- a/src/event.c +++ b/src/event.c @@ -111,6 +111,10 @@ static EVENT_CALLBACK(EVENT_HANDLER_APPLICATION_LAUNCHED) } } + //we are done depending on workspace, and its better to clear the observers than let them fire again + //if, somehow, e.g. activation policy changes again + workspace_application_destroy_running_ns_application(g_workspace_context, process); + return EVENT_SUCCESS; } ```that limits potential side-effects of #973 , I spent most of the evening working under the theory that the observers registered in
workspace_application_create_running_ns_applicationwere part of the problem – and technically that could still be true; :sweat_smile: )In any case, the issue seems to relate specifically to
https://github.com/koekeishiya/yabai/blob/8777db43b8551e0bc4e5c55d1e15bcbed52501a1/src/osax/payload.m#L672-L673
(essentially the code that sticks the border to the window - so it moves with it and stays on top of it as its contents change. commenting out calls to
scripting_addition_add_to_window_groupbut otherwise (visually dissatisfyingly) leaving borders on seems to eliminate issue)I think the issue is possibly these window groups breaking
[NSPersistentUIWindowSnapshotter captureAndWriteSnapshotForWindowNumber:forWindowID:waitUntilDone:]which I think is, these days, unfortunately on the path from a pretty vanilla[NSApplication -terminate](via[NSPersistentUIManager flushPersistentStateAndClose]?)I am not sure whether
yabaior the SA can insinuate itself early enough into the process to clear the way to avoid this conflict- I tried getting yabai notified onkEventAppQuitto no avail (I might have been doing something wrong, or AppKit just isn't reliably on Carbon anymore?);Maybe acting on remote
kAEQuitApplicationwill be more fruitful and sufficientBut in any case, there's always limelight :-)
Parallels 17 released today added support for macOS Monterey guests/VMs on M1 - but as yet I have not cracked getting it into Recovery Mode to disable SIP on the guest / I am not sure its doable. Doing
sudo nvram internet-recovery-mode=RecoveryModeDiskseemed to result in a normal/unchanged boot; doingsudo nvram internet-recovery-mode=RecoveryModeNetworkgot me stuck in a black screen in the guestI fear
that the VM doesn't include the recovery partition and/but(EDIT:diskutil listsuggests the recovery partition is allocated) that it doesn't initialize the frame buffer if netbooting.I'mma give it another shot or two, but if anybody else cracks it, share please :-) (Even with the PD17 macVM lacking snapshotting, etc as yet, ) I think it would be easier to deal with messing with the WindowServer et al when it doesn't crash my whole setup to do so
I found (using NationalSecurityAgency/ghidra on this JDK) and updated M1 SA call sites for beta 5 (21A5304g) - https://github.com/donaldguy/yabai/commit/654692d74e75b44c176f856ba2db43ee7a6497a8
yabai.zip