X11 no longer starts - it does again but now some GTk3 apps abort with a BadAccess

Jeremy Sequoia jeremyhu at apple.com
Sat Feb 17 17:00:13 UTC 2024


Over TCP, you might not be getting DRI and GLX, so that might be forcing GTK down some alternative codepath

Sent from my iPhone...

> On Feb 17, 2024, at 03:28, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> 
> Well, at 3h this morning I had it mostly working again. I think the order of mishaps was
> 
> 1) me setting PATH in the launchctl environment
> 2) before undoing that (and rebooting), me calling `startx` or running X11.app from a terminal as root with the idea that the IPC error might go away because of that
> 3) me seeing the warnings about .Xauthority and somehow thinking "I don't have that file anyway" rather than checking and discovering it had been "stolen" by root during 2)
> 
> So after fixing 3) and running `xauth -b` for good measure my X11 environment starts again.
> 
> I haven't yet had the chance to check if remote connections work, but local connections via `DISPLAY=hostname:0` do work again (they didn't with my hands-on call to `xinit` without `-auth` file).
> 
> Jeremy pointed out that we need privileged_startx, the launchctl plist I had moved aside for forgotten reasons. So I moved it back and loaded it before launching X11.app after the fixes above.
> 
> Before all this I'd been tinkering with epiphany, the Gnome WebKit browser, so that was the 1st thing I tried to launch from my restored X11 session.
> Boom, BadAccess and abort. `zenity --calendar` and `gtk3-demo-application` also do the same thing.
> 
> Curiously, they do NOT when I run them with `env DISPLAY=Portia.local:0.0 foo` .
> 
> Tracing shows the culprit is a call to XCreatePixmap from `gdk_window_set_icon_list`  (GTk 3.24.20).
> 
> Evidently I unloaded that privileged_startx plist, moved it back to its -disabled folder and restarted X11.
> 
> Now, these applications will start OK, but only for a few minutes in (or maybe just starting one triggers a who-knows-what that causes the BadAccess error on subsequent runs).
> 
> Needless to say, this is new.
> 
> Does this ring any bells, an X11 operation that raises a BadAccess when run over the local DISPLAY socket but not when it goes (IIUC!) via the TCP layer?
> 
> Thanks,
> R.


More information about the macports-users mailing list