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