User Profile

Happy New Year eskimo! The crash logs we collect from our customers are generated by PLCrashReporter I believe. It somehow yanks the system symbols out (sounds like a PLCrashReporter thing) and we don't have a convenient way to re-symbolicate that part. That said I'm fairly confident if we would symbolicate output_18765164.log it would produce exactly the same crashed stack as the bash one (apart from the fact of different parent processes). One more detail we recently figured out - we noticed that currently our crash reporter has a restriction built in our code that it's only able to properly process & upload crash logs if it's running with root access. Since we are getting these crash logs, it proves those processes have been launching as the root user, which seems to conflict with the fact that they are (at least supposed to be) registered as Launch Agent and should be running as the current logged in user? Again to me it still doesn't pinpoint the issue any further than our current speculation - it could still be a system bug/software bug/user tampering, but I thought to mention this new detail.

Radar ticket for this - FB9800999

SessionGetInfo sounds like a great idea! I'll forward it to our team. can you post a full crash report? Yes I can help with that. We already have a radar ticket on the original AppKit crash. Let me ask my colleague who filed it about the number and get back here. It's around the holidays though I might not be able to reach him soon. And in the likely case I don't post any feedback until New Year just want to wish you Happy Holidays Eskimo (and of course to anyone who stumbles on this post around this time of year), your help and advice are always appreciated!

Thanks for the pointer to the Technote Eskimo! It was good reading. I presume that you’re not in touch with any of these users? That is unfortunately true. From crash logs alone we currently have no means to backtrack to the specific users. We'll have to wait for the users to come contacting us instead. Given that the crash is likely only happening without a GUI session it's likely they would not notice it for quite a while (or maybe not at all). For now I think my interpretation of your answer is that from the OS point of view, there is no official way (at least no known one) to be able to launch an agent under the Aqua type (and yes our launchd.plist doesn't specify LimitLoadToSessionType) while denying it access to the graphic context. So the users must have somehow either "monkeyed" with the system, or like you suggested, with our config. Assuming our hypothesis is true and there is no good option to prevent end users from doing what they are doing, currently our team has come up with an idea of detecting this situation (no GUI context) during our agent's startup in hoping to skip the entire AppKit entry call. Specifically we are thinking of calling CGWindowListCopyWindowInfo(kCGWindowListOptionAll, kCGNullWindowID) before we engage all UI related stuff. We verified that if we call this without graphic context we would get nil while otherwise we would get an array with something, which serves as an indicator to us. Does this sound like a practical idea or is there perhaps anything we overlooked?

Thank you The Eskimo as always!

Answering my own question here in case anyone comes across the same. I figured out this crash happens if we call [[NSStatusBar systemStatusBar] statusItemWithLength:NSSquareStatusItemLength] when a graphic session is not available. E.g. if the code is executed through an ssh session without the same user on any active GUI session. Interesting that I tried the same with older macOS versions I don't see the crash (while I do see some error messages printed on console). It matches the fact that our crash reports have all been coming from macOS 12. What I still don't understand is that how come our code has been executed if there is no GUI (it is registered as a LaunchAgent) but I've opened a new post for that discussion (https://developer.apple.com/forums/thread/696859).

Thanks Matt! Looks like it is not enforced for remote connections either. Filed a ticket FB9716553. From some logs we came through it looks like the Network framework tried to upgrade the connection to HTTPS and failed (expected because we didn't enable HTTPS on the target host during the test) and then it just fell back. Still to our own concern - being this close to release we don't expect this behavior to change in GA right? ;p