I have a bug that I have a functional workaround for, but would like a clean solution. I have the higan emulator on my machine (OS is Archlinux derivative based) to run the retro games from when I was a kid. I use Awesome window manager and not a formal desktop environment, which may be relevant. When I first launch X (and Awesome) via
startx, attempts to run the emulator fail. I can get an error message by launching from xterm with
higan & The program hiro received an X Window System error. This probably reflects a bug in the program. The error was 'BadAtom (invalid Atom parameter)'. (Details: serial 9 error_code 5 request_code 20 minor_code 0)
The error message continues with the standard language about X errors being asynchronous and using –sync to perform a trace. The program fails immediately here without opening any window at all. Xorg.0.log does not log an error.
This is the weird part. The error is “unfixable” in that it happens on successive attempts to run the program, every time, with the same message. However, after I run the web browser, the next attempt to run higan succeeds, and all subsequent attempts succeed. I can revert the system to the error state by dropping out of X and into the Linux text virtual terminal (in Awesome, this is as simple as
Mod4-Shift-Q) and running
startx again. Upon reentering the X environment, higan is broken with the same error until running the browser. It looks like any firefox core browser works, as tor-browser fixes the error too. I have not tried other programs yet (e.g. libre office).
I have limited understanding of development in the X graphical environment. My understanding of X atoms is that they are indexes into a string table of properties in the X server. This is used, among other things, to transfer data between programs. Given this, it looks to me like there is a “server level” property table that various programs can see, and higan attempts an unprotected access to a property with a crash if it is not set, while firefox checks if the property exists and if not, in some way initializes it, so that the next higan access is successful. This may explain why my bare bones Awesome environment has this problem but the average Desktop user does not. Awesome basically runs nothing on startup, it reads the config file which sets shortcut keys and builds a menu, etc.
Is there anyone on the forum who, ideally, knows what the offending Atom is and how it can be cleanly initialized without the ugly hack of starting the browser before the emulator? If not, is there anyone well versed in X development that can recommend how to figure out what the offending Atom is without reverse engineering the higan source code? I have reached out to the developer (byuu) who has never seen this issue and warned me that debugging X errors is a nightmare.