macOS 12 Monterey #923
Comments
|
Appreciate 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 |
|
this 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 |
|
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 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 |
|
@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 ~
❯ yabai
fish: Job 1, 'yabai' terminated by signal SIGKILL (Forced quit)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 |
|
In my case, I had to revert the following two commits and keep using frida to make it work on 12 beta 1: |
|
@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 have tested that the master branch builds fine for me on macOS Big Sur 11.6.1 (Intel) and macOS Monterey 12.0.1 (Apple Silicon). Both builds work when I send them to my other device, both ways. Make sure your Xcode is up to date. Also what is the output of Here is a pre-built version (with debug symbols) of commit (727b112): yabai-v4.0.0.tar.gz I have verified that it runs on both arm64 (12.0.1) and x86-64 (11.6.1). Edit: I am using Xcode v13.1 (13A1030d) on both devices (not command line tools) and Apple clang version 13.0.0 (clang-1300.0.29.3). |
|
With yabai from --HEAD, SIP totally disable, codesigned I still get this warning and I cannot install payload: ❯ yabai -v
yabai-v4.0.0
❯ sudo yabai --load-sa
could not set thread state: (os/kern) protection failure
yabai: scripting-addition failed to inject payload into Dock.app!
❯ csrutil status
System Integrity Protection status: disabled.EDIT: I am on a MacOS M1: ❯ neofetch
'c. storopoli@Duda-M1
,xNMM. -----------------
.OMMMMo OS: macOS 12.0.1 21A559 arm64
OMMM0, Host: MacBookAir10,1
.;loddo:' loolloddol;. Kernel: 21.1.0
cKMMMMMMMMMMNWMMMMMMMMMM0: Uptime: 9 mins
.KMMMMMMMMMMMMMMMMMMMMMMMWd. Packages: 284 (brew)
XMMMMMMMMMMMMMMMMMMMMMMMX. Shell: zsh 5.8
;MMMMMMMMMMMMMMMMMMMMMMMM: Resolution: 1440x900
:MMMMMMMMMMMMMMMMMMMMMMMM: DE: Aqua
.MMMMMMMMMMMMMMMMMMMMMMMMX. WM: yabai
kMMMMMMMMMMMMMMMMMMMMMMMMWd. Terminal: tmux
.XMMMMMMMMMMMMMMMMMMMMMMMMMMk CPU: Apple M1
.XMMMMMMMMMMMMMMMMMMMMMMMMK. GPU: Apple M1
kMMMMMMMMMMMMMMMMMMMMMMd Memory: 1109MiB / 8192MiB
;KMMMMMMMWXXWMMMMMMMk.
.cooc,. .,coo:.
|
|
@storopoli You probably have not yet changed the boot-args to allow for non-Apple-signed arm64e binaries. |
I have the exact same version of these two things. I tried the prebuilt file you shared (thank you so much). It works well so far. But still wondering why brew doesn't work... and now I cannot do the |
|
I get the following error on the System recovery Terminal: nvram boot-args=-arm64e_preview_abi
Error setting variable - 'boot-args': (iokit/common) not permitted.And the output of System Integrity Protection status: unkown (Custom Configuration).
Configuration:
Apple Internal: enabled
Kext Signing: enabled
Filesystem Protection: disabled
Debugging Restrictions: disabled
DTrace Restrictions: enabled
NVRAM Protections: disabled
BaseSystem verification: enabled
Boot-arg Restrictions: disabled
Kernel Integrity Protection: disabled
Authenticated Root Requirement: enabled |
|
@storopoli I got the same error. Run |
|
Same issue here. M1 Macbook Pro, Xcode 13.1. I have re-enabled SIP and cleared nvram boot arguments to defaults so that I can go all the way through the process again twice now, but still receive when loading the scripting addon. |
I tested it with the newest master version and with my rules enabled and that solved it for me!! |
You are correct; I see the same behaviour. I have updated the wiki so that it mentions that this command must be run as root after exiting recovery mode and rebooting. Previously it was possible to run the nvram command in recovery mode after SIP had been disabled (possibly can be done in recovery after a reboot between the initial command to disable SIP, but then it might as well be done from a normal user session using sudo). Did you reboot after changing the boot-args? I am unable to reproduce a failure in That's great, hopefully it remains stable for the most part. |
|
Thank you so much for the work to get this running for Monterey. It's a shame that window borders don't work anymore, but I'm happy to have my window tiling back! However, System details: |
|
@koekeishiya I am still getting the same error after several reboots: ❯ csrutil status
System Integrity Protection status: unknown (Custom Configuration).
Configuration:
Apple Internal: disabled
Kext Signing: enabled
Filesystem Protections: disabled
Debugging Restrictions: disabled
DTrace Restrictions: enabled
NVRAM Protections: disabled
BaseSystem Verification: enabled
Boot-arg Restrictions: disabled
Kernel Integrity Protections: disabled
Authenticated Root Requirement: enabled
This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.
❯ xcode-select -p
/Library/Developer/CommandLineTools
❯ sudo nvram -p | grep boot
boot-volume EF57347C-0000-AA11-AA11-00306543ECAC:576803DC-8B8D-BE42-9141-4141C7094374:FAFD0CFB-7CCB-49C0-9981-FF31A5E49942
upgrade-boot-volume EF57347C-0000-AA11-AA11-00306543ECAC:576803DC-8B8D-BE42-9141-4141C7094374:5F9234CF-C7F4-496F-B5F4-646CA2537157
boot-args -arm64e_preview_abi
❯ yabai -v
yabai-v4.0.0
❯ sudo yabai --load-sa
could not set thread state: (os/kern) protection failure
yabai: scripting-addition failed to inject payload into Dock.app! |
|
You can look for logs in
|
|
@storopoli Can you post the output of the following: This is what it should look like: |
|
Here it is: ❯ cat /Library/ScriptingAdditions/yabai.osax/Contents/Info.plist | grep -A 1 CFBundleVersion
<key>CFBundleVersion</key>
<string>2.0.0</string>
❯ file /Library/ScriptingAdditions/yabai.osax/Contents/Resources/payload.bundle/Contents/MacOS/payload
/Library/ScriptingAdditions/yabai.osax/Contents/Resources/payload.bundle/Contents/MacOS/payload: Mach-O 64-bit dynamically linked shared library arm64
❯ file /Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_loader
/Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_loader: Mach-O 64-bit executable arm64 |
|
Well the issue is that for some reason your scripting-addition is not being built as a universal binary. I don't really know why that is. The current master builds a universal binary on both my Intel MacBook running 11.6.1, and my Apple Silicon MacBook running 12.0.1. Note that I am not using brew while testing, so maybe that could somehow cause a difference in compilation, even though it uses the same makefile?? I'm not sure how to debug that issue further. |
|
I will try to build from master without brew |
|
I cannot build from master: sudo make install
rm -rf ./bin
clang ./src/osax/loader.m -shared -O2 -mmacosx-version-min=10.13 -o ./src/osax/loader -framework Foundation
clang ./src/osax/payload.m -shared -fPIC -O2 -mmacosx-version-min=10.13 -arch arm64e -o ./src/osax/payload -framework Foundation -framework Carbon
./src/osax/payload.m:29:10: fatal error: 'ptrauth.h' file not found
#include <ptrauth.h>
^~~~~~~~~~~
1 error generated.
make: *** [src/osax/loader_bin.c] Error 1
|
|
I wonder what exactly is causing the command run from the makefile to differ from the one actually at the master branch. Do you have some custom clang version installed that takes precedence over the XCode / command line tools version? This seems likely to me as it appears that a standard header that should be included, is in fact not. This is the line i expected to see: Notice how it refuses to build a universal binary containing two images; the x86_64 part is just stripped from your version, which shouldn't happen. |
|
Ok, I think I got this. I've installed with Then I did this (a kinda hack): ❯ cd Desktop/archive/bin/
mv yabai /opt/homebrew/Cellar/yabai/HEAD-6bcf544/bin/yabai
override r-xr-xr-x storopoli/admin for /opt/homebrew/Cellar/yabai/HEAD-6bcf544/bin/yabai? (y/n [n]) yIt seem to be working now. |
|
Closing in favour of #1054. |
For whatever reason, this worked. I tried brew install head and sudo make install and I'm pretty confident that I followed the instructions to the letter. After I saw this comment, i removed all old installations and did a |
I had done, but I see you've tracked down the issue, my results mirror that of @storopoli. The hack of replacing the binary with the pre-compiled copy has also worked for me. Thanks to you both. Good luck in tracking down the issues with the Brew process! And thanks for such a great piece of software. |
I'm running Monterey on Intel, it's hard to follow what solutions in that thread are for Monterey and what issues are for M1. |
|
Install the latest version released (v4.0.0) either through brew or grab it from the GitHub releases page. |
|
@koekeishiya thanks! After upgrading 3.3 -> 4.0, it looks like that fixed the scripting additions notification spam. |
and others
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.
Click to expand build log
The text was updated successfully, but these errors were encountered: