Closed dominiklohmann closed 3 years ago
First noticed in | Fixed as of |
---|---|
20A4299v |
- |
First noticed in | Fixed as of |
---|---|
20A4299v |
20A5354i |
The new modal sheet windows used by print dialogs, alerts and popovers report a primary role of AXSheet
and cannot be moved. I suggest yabai should ignore them like AXPopover
and AXUnknown
windows.
Update: This is as simple to fix. Together with the AXSheet
window, macOS creates a new pseudo window, just like for native tabs, which is why the tiling occurs. The AXSheet
windows themselves aren't tiled. This may be fixed implicitly by fixing #68.
Update 2: This is fixed as of beta 5 (20A5354i
), which removes the additional transparent standard window.
The uploaded SkyLight.framework doesn't include the actual binary.
@koekeishiya The uploaded SkyLight.framework doesn't include the actual binary.
From the release notes: https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11-beta-release-notes/
New in macOS Big Sur 11 beta, the system ships with a built-in dynamic linker cache of all system-provided libraries. As part of this change, copies of dynamic libraries are no longer present on the filesystem. Code that attempts to check for dynamic library presence by looking for a file at a path or enumerating a directory will fail. Instead, check for library presence by attempting to
dlopen()
the path, which will correctly check for the library in the cache. (62986286)
I suppose this is the issue, and it's bad. I'll look into finding a way to dump the library after I've loaded it at runtime.
You'd probably need to write (or find an existing tool?) that inspects the memory of a process that has already loaded the SkyLight.framework, using task_for_pid and dump the appropriate section.
f8a01b9 did not fix the scripting addition for build 20A4299v.
thread: 300420544 | yabai: osax version = 1.0.15, osax attrib = 0x0
I'll likely just run some further stress tests over the coming days and weeks. I'm currently dual-booting the beta, because I did not want to run it on my daily driver.
I think the biggest difference so far is AXSheet
. I've made some local changes to ignore the window role, ~which seem to work fine in my initial testing.~ Edit: turns out that there's additionally a new invisible standard window when an AXSheet window is created, which has the same symptoms as #68: Exact same window frame as the original window, and shows as non-resizable.
Can you create a sample executable and check which major and minor version NSOperatingSystemVersion
outputs on Big Sur? I assumed it would be 10.16 based on the product version in your first post. The offsets and patterns should be correct - located them manually using IDA.
Edit: I am stupid. Fixed the pattern lookup, but didn't whitelist the version itself.
Heh, just created https://github.com/koekeishiya/yabai/pull/594 to fix it before seeing that you did it locally. Feel free to close my PR. I've added code to print the version alongside the SA version and lookup result.
Regarding AXSheet
, I've noticed that the invisible standard window à la #68 is always created immediately after the AXSheet
window. This could be used for tagging the next window id as ignored, if the calls to the window manager state were to happen synchronously. I'm not quite sure on the implications of this or whether this order is guaranteed, but I'll likely play around with that over the coming days as well.
So after testing some more, here's what's working and what isn't with the scripting addition as of b3545fa:
Is the value of osax attrib 0x3f? Maybe I messed up some of the patterns, or there must have been some other kinds of changes.
It's 0x3B actually.
Looks like you simply forgot get_add_space_offset
, it's the only of the offset/signature-returning functions that was not touched for the initial Big Sur update.
Right, should be fixed now. So I don't actually get why focusing spaces don't work though. Will likely be hard for me to solve that without actually running the OS and being able to iterate on some changes.
So I don't actually get why focusing spaces don't work though.
It was a user error. The update re-enabled the default keybindings under the Keyboard pane in System Preferences, and these shortcuts take precedence. They do, however, not work with fullscreen spaces, and I was testing with a single non-fullscreen space only.
Can you move fullscreen spaces around? If so I have no clue why focus wouldn't work, as they both access the same internal methods to interact with spaces.
Ah I think you're misunderstanding, I should've worded that clearer. Focusing spaces does work—it was a user configuration error.
Oh right, yeah, I get what you meant now. Everything seems to be working then, which is great.
BeanieBen9990 commented 8 hours ago •
Loading the scripting addition makes right clicking icons on the dock crash it. Right clicking any icon on the dock with the SA loaded crashes the dock immediately. Sometimes this also causes a notification that instead of the SA being reloaded, that is couldn't load and to make sure SIP is disabled (which it is)
I'm guessing you've already got Skylight.framework, but if you haven't, the article Extract the system libraries on macOS Big Sur might be useful...
@pcr910303 Thank you so much, that looks like it should work exactly for our needs. I was not able to spend time on this yet.
Build 20A4300b
is out (beta 2). Everything seems to still work just fine.
I'll try extracting the Skylight binary for this one over the weekend; currently quite busy with work and can't always run Big Sur.
This seemed fairly random to me, likely a timing issue. My computer was running under a very high load when this occurred. This seems to happen within display_manager_focus_display_with_point
from looking at the backtrace.
First noticed in | Fixed as of |
---|---|
20A4300b |
- |
Probably the call to CFEqual in display_manager_find_element_at_point. I really would not expect an axuielement to be unable to report a role at all - if so, what is the point of having the unknown value.
Sent from my iPhone
On 10 Jul 2020, at 11:27, Dominik Lohmann notifications@github.com wrote:
Bug: CFEqual() called with NULL first argument
This seemed fairly random to me, likely a timing issue. My computer was running under a very high load when this occurred. This seems to happen within display_manager_focus_display_with_point from looking at the backtrace.
First noticed in Fixed as of 20A4300b - Click to expand crash log
Process: yabai [475] Path: /usr/local/opt/yabai/bin/yabai Identifier: yabai Version: 0 Code Type: X86-64 (Native) Parent Process: ??? [1] Responsible: yabai [475] User ID: 501
Date/Time: 2020-07-10 11:23:11.037 +0200 OS Version: Mac OS X 10.16 (20A4300b) Report Version: 12 Bridge OS Version: 5.0 (18P50310o) Anonymous UUID: CA73AB6B-4198-F78E-B7DD-8A6D012A5059
Sleep/Wake UUID: 2570F97D-D91F-4ABA-A7F4-1A1AF521BE6B
Time Awake Since Boot: 15000 seconds Time Since Wake: 9200 seconds
System Integrity Protection: disabled
Crashed Thread: 1
Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0000000000000001, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Illegal instruction: 4 Termination Reason: Namespace SIGNAL, Code 0x4 Terminating Process: exc handler [475]
Application Specific Information: CFEqual() called with NULL first argument
Thread 0:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff6c3e225e mach_msg_trap + 10 1 libsystem_kernel.dylib 0x00007fff6c3e25d0 mach_msg + 60 2 com.apple.CoreFoundation 0x00007fff2c5d7cee CFRunLoopServiceMachPort + 247 3 com.apple.CoreFoundation 0x00007fff2c5d6783 CFRunLoopRun + 1315 4 com.apple.CoreFoundation 0x00007fff2c5d5bea CFRunLoopRunSpecific + 534 5 com.apple.CoreFoundation 0x00007fff2c65b9a1 CFRunLoopRun + 40 6 yabai 0x000000010be69315 main + 1877 7 libdyld.dylib 0x00007fff6c282c71 start + 1
Thread 1 Crashed: 0 com.apple.CoreFoundation 0x00007fff2c70455e CFEqual.cold.1 + 14 1 com.apple.CoreFoundation 0x00007fff2c560a39 CFEqual + 673 2 yabai 0x000000010be5c53e display_manager_focus_display_with_point + 126 3 yabai 0x000000010be6ed87 EVENT_HANDLER_MOUSE_MOVED + 967 4 yabai 0x000000010be476b8 event_loop_run + 104 5 libsystem_pthread.dylib 0x00007fff6c4ae9b4 _pthread_start + 224 6 libsystem_pthread.dylib 0x00007fff6c4aa4d7 thread_start + 15
Thread 2: 0 libsystem_kernel.dylib 0x00007fff6c3e88c6 __accept + 10 1 yabai 0x000000010be44e66 socket_connection_handler + 70 2 libsystem_pthread.dylib 0x00007fff6c4ae9b4 _pthread_start + 224 3 libsystem_pthread.dylib 0x00007fff6c4aa4d7 thread_start + 15
Thread 3: 0 libsystem_pthread.dylib 0x00007fff6c4aa4b4 start_wqthread + 0
Thread 4: 0 libsystem_pthread.dylib 0x00007fff6c4aa4b4 start_wqthread + 0
Thread 1 crashed with X86 Thread State (64-bit): rax: 0x00007fff2c910aae rbx: 0x00007fc155410220 rcx: 0x00007fff6c3e21da rdx: 0x0000000000000001 rdi: 0x0000000000000000 rsi: 0x000000010bea9430 rbp: 0x0000700005397ad0 rsp: 0x0000700005397ab8 r8: 0x000000000000801f r9: 0x00000000000003e8 r10: 0x00000000ffffffff r11: 0x0000000000000297 r12: 0x000000010bebe298 r13: 0x0000000000000000 r14: 0x0000000000000000 r15: 0x00007fc156a05150 rip: 0x00007fff2c70455e rfl: 0x0000000000010246 cr2: 0x00007fe5e54fa018
Logical CPU: 2 Error Code: 0x00000000 Trap Number: 6
Binary Images:
0x10be40000 - 0x10be76ffb +yabai (0)
External Modification Summary: Calls made by other processes targeting this process: task_for_pid: 132 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: 62760 thread_create: 0 thread_set_state: 0
VM Region Summary: ReadOnly portion of Libraries: Total=650.4M resident=0K(0%) swapped_out_or_unallocated=650.4M(100%) Writable regions: Total=218.5M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=218.5M(100%)
VIRTUAL REGION
REGION TYPE SIZE COUNT (non-coalesced) =========== ======= ======= Activity Tracing 256K 1 CoreGraphics 4K 1 Dispatch continuations 96.0M 1 Foundation 16K 1 Kernel Alloc Once 8K 1 MALLOC 111.9M 43 MALLOC guard page 32K 8 Memory Tag 242 12K 1 STACK GUARD 56.0M 5 Stack 10.0M 5 VM_ALLOCATE 792K 13 DATA 24.5M 296 DATA_CONST 32K 1 FONT_DATA 4K 1 LINKEDIT 448.6M 8 OBJC_RO 35.4M 1 OBJC_RW 2304K 2 TEXT 201.9M 294 UNICODE 588K 1 mapped file 64.0M 14 shared memory 40K 4 =========== ======= ======= TOTAL 1.0G 702
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/koekeishiya/yabai/issues/589#issuecomment-656580874, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABPDZV5TVGI2YFKHG67G4TDR23NJLANCNFSM4OFDJTJA.
I really would not expect an axuielement to be unable to report a role at all - if so, what is the point of having the unknown value.
Maybe since my computer was running under a very high load at that time the call to the AX API timed out, hence it returning NULL
. But that's just guessing at this point. I have not managed to reproduce the issue.
Maybe since my computer was running under a very high load at that time the call to the AX API timed out, hence it returning NULL.
Right, I keep forgetting about the stupid timeout that I set to 1sec; that makes sense. I think this is a really bad design decision, but it is done for reasons hinted to in #599 , #600, and I would like to handle the situation better. I had some initial thoughts, but they require a fairly large restructure and so I wanted to see if people had some thoughts.
This is actually a terrible bottleneck which cripples the current design I have implemented. If it isn't a huge problem in practice it may not be worth trying to improve upon it. Of course due to the nature of macOS it will never be perfect, but the current solution can definitely be improved upon. This really is an area that is hard to do correctly.. by the third iteration I knew enough to make something that is fairly stable at least, but maybe a 4th has to be done at some point.
Build 20A5323l
is out (beta 3).
sw_vers
reports the version as 11.0 now.
❯ sw_vers
ProductName: macOS
ProductVersion: 11.0
BuildVersion: 20A5323l
Setting SYSTEM_VERSION_COMPAT=1
causes the version to be 10.16. This works for all applications, including yabai.
❯ SYSTEM_VERSION_COMPAT=1 sw_vers
ProductName: Mac OS X
ProductVersion: 10.16
BuildVersion: 20A5323l
Running sudo yabai --install-sa
returns exit code 2. I'll investigate once I have time. The command fails to write the scripting addition to /Library/ScriptingAdditions
.
Despite an older verison of yabai.osax
still being installed, yabai reports that the scripting addition is not installed.
~Building yabai from source is broken with LLVM Clang compiled from source, and requires using xcrun clang
now to explicitly use AppleClang. Otherwise the libraries cannot be found.~ This can be fixed by downloading the updated command line tools and re-building LLVM Clang.
The overall stability of macOS seems to have increased greatly. This beta feels much more responsive. I've added a zipped Dock.app
to the first post, and will investigate the loading issue once I have time to meddle with the beta again.
Big Sur Beta 4 20A5343i
is out. The new Dock.app is in the first post.
The scripting addition needs to be updated (osax attribute is 0 / all patterns need to be updated). Nothing else seems to have changed for yabai.
All listed issues still apply, most notably the issue with the new sheet windows and the right-click crashes for the Dock.
Updated scripting-addition for build 3 and 4.
What does one need to get them running? The Dock files from the top of the Thread?
@koekeishiya Updated scripting-addition for build 3 and 4.
Thanks. Everything is working.
@24unix What does one need to get them running? The Dock files from the top of the Thread?
No, these are only needed so they can be looked at with the usual reverse engineering tools for updating patterns. All you need to do is to install the current master of yabai (and the current scripting addition).
When I want to install the scripting addition on macOS Big Sur Beta 20A5343i, I get the following errors:
I looked in other threads, but couldn't find a solution. But maybe this is relevant:
yabai: osax version = 1.0.14, osax attrib = 0x0
/Library/ScriptingAdditions/yabai.osax
existsI first tried to install the scripting addition wiht SIP partly disabled, then I totally disabled it and reinstalled the addition. But still it does not work.
EDIT: Sorry, I did not notice that I have to install from -HEAD. Now it works.
Beta 5 is out. Build: 20A5354i
. The scripting addition needs to be updated.
yabai: osax version = 1.0.18, osax attrib = 0x5
As usual, I've attached the Dock.app to the first post of this thread.
The AXSheet
issue is resolved, there no longer is an additional transparent standard window involved.
Right clicking the dock still crashes.
Beta 6 is out, build 20A5364e
. ~The scripting addition needs to be updated.~ Fixed with osax version 1.0.20
.
yabai: osax version = 1.0.19, osax attrib = 0x3E
As usual, I've attached the Dock.app to the first post of this thread.
Right clicking the dock still crashes.
Hello, could you please tell me how to install Dock.app and SkyLight provided at the first comment? Should i use --HEAD version of yabai or build from latest commits?
Hello, could you please tell me how to install Dock.app and SkyLight provided at the first comment?
You are not supposed to install them, they are simply listed here for analysis purposes.
Got it, thank you
Having problems with executing commands (Resize window, switch spaces etc.) on last beta version ( Previous beta worked fine). Windows tilling works correctly.
Having problems with executing commands (Resize window, switch spaces etc.) on last beta version ( Previous beta worked fine). Windows tilling works correctly.
Can confirm these commands no longer work in the latest beta 11.0 Beta (20A5364e)
Edit: HEAD works fine
Got it, thank you
Having problems with executing commands (Resize window, switch spaces etc.) on last beta version ( Previous beta worked fine). Windows tilling works correctly.
in current beta 6, i have to run brew services restart yabai
every reboot to have executing commands worked. window tiling is ok though. not sure if anyone got the same issue.
Beta 7 (build 20A5374g
) is out, and it brought some trouble along with it.
I've attached the Dock.app to the first post of the thread.
Loading the scripting addition crashes Dock.app, causing an infinite loop of Dock.app restarting and yabai trying to load the scripting addition.
yabai --verbose
:@dominiklohmann Do you have the crash report for Dock.app as well. The yabai output isn't particularly useful here.
Sure thing, here you go.
I haven't had any time to play around with it yet, because I can't run this beta as my daily driver: Apple hasn't released the command line tools containing the MacOSX11.0.sdk files since beta 5, and I kinda need some of the things in there. 🤷♂️
Application Specific Information: dyld3 mode 67020474 bear trap: NSApplication initialized in Dock. Please log a bug.
Looks like we might need to find some other way besides scripting-additions to inject code.
This looks really bad. There's no way around the NSApplication initialization with an OSAX, right?
Not that I know of, no.
Beta 8 (build 20A5374i
) was just released. I've added the Dock to the first post for completeness.
Could you also post the Dock output from Console.app, similar to what is seen in the following screenshot:
By the looks of it the crash happens while loading the payload bundle (inside the loader code triggered here). I wonder if we could make adjustments there; instead of loading the code out of a bundle and relying on obj-c class hierarchy to trigger the [payload load] function, we should be able to simply dlopen a shared obj. file and execute it ourselves.
Here you go. I've filtered by process:Dock
, and pasted from the point of running sudo yabai --install-sa
.
FYI the public beta 4 which is the exact same build as developer beta 8 was just released (developer beta 7 did not have a public beta), so there'll be some people complaining about yabai causing Dock to restart constantly because they still have an OSAX installed.
I made some adjustment to the loader in the lastest commit. Can you check if that one is able to load the payload?
Still the same crash as of 2b58ce8
Here's the usual yearly thread.
I'll try to keep this thread updated for the latest developer beta until macOS Big Sur is released. I will hide replies that are not or no longer relevant to keep the thread readable, unlike last year's.
Disclaimer
General Information
20A5323l
the product version is reported as 11.0.Relevant System Files
20A4299v
20A4300b
20A5323l
20A5343i
20A5354i
20A5364e
20A5374g
20A5374i
20A5384c
20A5395g