This is just a result of the freeze not the cause, it's just the log reporting that the window froze and not that the window server is the cause, anyway from a dozen logs I've seen the messages there don't really help because they don't explain exactly what happened and basically just report what's happening on the surface.
But did I mentioned that WindowServer is the
cause of the freeze?
I just repeated what watchdogd prints out into the system log.
According to terminal man page: „
watchdogd is part of the watchdog infrastructure, it ensures that both the kernel and user spaces are making progress.“ If watchdogd reports that WindowServer is not responding, we can assume thats more or less the only process in kernel and user space that is not responding. Otherwise watchdogd will report other and more processes as not responding.
During one freeze that I had on my Mac I could still successfully connect to a running ssh deamon. In this terminal session I tried to kill WindowServer process, but this was not possible. I also tried to kill WindowServer before the freeze happen witch was possible and restarts the GUI of cause. We can count this as an indication that WindowServer is really not responding and that the watchdogd is not fantasizing when printing this into the system log file.
As far as we know from
„Mac App Programming Guide“ published by Apple the WindowServer
"is responsible for tracking mouse, keyboard, and other events and delivering them to your app." and
"the window server delivers events, the app queues those events and then processes them sequentially in the app’s main run loop."
This means if the WindowServer is not responding it is at least the cause why mouse, keyboard and other events are no longer delivered to any application in OSX witch is of cause the behavior that a normal user that interact with the system will call „frozen“.
As you emphasise with your post this does not mean that we know the exact reason
why the WindowServer is not responding. Yeah, thats true. But at the end it is the bloody job of the Apple engineers to find that cause and to fix it.
I disassemble the WindowServer just for curiosity witch seems pretty useless afterwards since this program only loads the CoreGraphics.framework and calls the function _CGXServer in it. But now we can at least say
„a part of CoreGraphics.framework freezes“ instead of the ignorant „ the WindowServer freezes“ whitch is indeed a big step forward. Absolutely! Oh, wait a minute…. We still did not know the exact cause why a part of CoreGraphics.framework freezes or don’t we? So it’s not a big step forward…? Damn!
I also take a look into the CoreGraphics.framework too. But this is really huge and complex binary and I saw just from the function names that it implements and calls that it did pretty much everything related to the GUI in OSX, the connection to IO.framework (e.g. contact to graphic drivers, USB drivers, HID drivers, mouse drivers, keyborad drivers, etc.), do all the event handling, do the window handling and drawing and much much more. Way too much for me to find the cause while reading in the mashine code.
The cause can be a coding error in CoreGraphics (e.g. pending on a semaphore/mutex that is never released, waiting for another thread, an endless loop, a function call that never returns….) or a bug in the XNU kernel or an issue in any of the used drivers (e.g. the Intel graphic drivers)… it is up to the Apple engineers to find it.
