Some GTk3 applications aborting with BadAccess when DISPLAY=:0 but not DISPLAY=hnam.local:0 or even DISPLAY=unix:0

I've had some issues with my XQuartz environment not starting due to a bit of a freak reason that was a rather hard to figure out. It's (mostly) working again but I must have caused another regression during my various troubleshooting attempts. Applications like epiphany, gtk3-demo-application and even zenity --calendar used to start just as you'd expect. Now, they abort because of a BadAccess that apparently occurs through the XCreatePixmap call under gdk_x11_window_set_icon_list. Strange, because I don't see that as a possible error for XCreatePixmap. Even stranger: it does **not** happen if I start these applications with DISPLAY=hnam.local:0 (or even unix:0!) rather than just DISPLAY=:0. From what I know this makes the connection go through the TCP/IP stack. Acceptable as a workaround as the performance/functionality loss is probably moot under XQuartz but I'd still like to understand what's up here. I'm suspecting that it's got something to do with the fact that I did use the privileged_startx wrapper that is normally enabled for XQuartz users and is responsible for setting up the directories under /tmp. I disabled that years ago for reasons I cannot recall, but re-enabled during my troubleshooting. It's disabled again, and since I did that there's another strange phenomenon. I can start the offending applications like before just after launching my X11 environment. A couple of minutes later they will again throw a BadAccess on start. Or maybe I can start them just once which will trigger whatever causes the BadAccess on subsequent starts. EDIT: but see below *) I had X11 configured (and hopefully have, again) to allow connections from remote servers in my LAN. I also always do a xhost +x because there's no reason for any tighter form of connection control. During my troubleshooting I also caused a brief issue with my .Xauthority file (got owned by root), which I fixed by re-owning it and running xauth -b. Do the above symptoms ring any bells? Could they be related to what's in those directories under /tmp or to something fishy in my .Xauthority file? It seems rather weird that operations would violate rules when performed from the most local kind of connection but not from remote connections, no? Thanks! EDIT: I have a hunch of the direct reason, but still no explanation why this has started happening. My X11 session is "anchored" by an xfce4-panel. It looks like the offending XCreatePixmap call might be targetting a drawable that's owned by that panel process, e.g. to install the application icon in the panel's "window button". It would make sense to do this only if the 2 XDisplay strings are identical. That could explain why I can also avoid the error with DISPLAY=unix:0 (AFAIK that's equivalent to DISPLAY=:0). As I said, I still can't fathom why this worked before, and even less why it now works for a limited amount of time. EDIT: it also seems I misinterpreted what xwininfo showed me. I've cobbled together an XIOErrorExitHandler that checks an env. variable to know it an attempt should be made to continue. That seems to work. EDIT: running e.g. sudo zenity --calendar also doesn't throw a BadAccess which again points in the direction of a file that no longer has the correct permissions. *) EDIT: and the weirdest observation of all: there is in fact no actual delay; the time aspect was introduced by me postponing one of my usual operations: moving the initial terminal windows to the desired screen (if it's attached) and height-maximising them via the WM (xfwm4). Changing the height of 1 of these 2 windows (belonging to separate Konsole5 instances) triggers the issue *and it goes away if I restore that window's initial height*. If I close the window the trigger action moves to the other window. Annoyingly I cannot find any indication what request_code 133 stands for.