xfce4-session segfault on startx

[arcctgx]

Hi,

After recent @world update I started having problems with starting XFCE. I'm normally starting Xserver from the command line with "startx" (I'm not using a login manager). I have NVidia GeForce GTS 450 GPU with the proprietary driver nvidia-drivers-390.157. What happens is that after "startx" xfce4-session segfaults, causing the X server to terminate.

My .xinitrc contains the following command to start XFCE:

[pingtoo]

arcctgx,

I am just simple xfce user. and I don't know much about dbus and xwindow.

From your debug code it seems "xfconfd" run into problem.

The xfconf_init() want to talk to dbus at this point and there are two functions in xfconf_init()

• g_bus_get_sync()
  
• g_dbus_proxy_new_sync()

both in glib.

So I suggest you review your current dbus setting/running state. may be there you can find some clues to help you further investigate.

On my machine I have display manager start my X.

[mike155]

[arcctgx]

Thank you for your answers.

[ukky]

arcctgx,

Segfault line says EIP is 0. This is abnormal and definitely is a bug.
Your Xorg.0.log is good.
Adding debug print statements to the segfaulting program was the way to go when I was debugging similar issue when X starts.
Do you have experience patching source code?
Another way to debug this issue would be to recompile libxfconf.so, libgio.so, and libglib.so with debug info. This way you'd have meaningful bt output in gdb.

[ipic]

So, I woke up this morning to this problem - having done an @world update to pick up the 6.7.7 kernel.
I ruled out the kernel as an issue by booting back to 6.7.6

Then I went through the "what changed" routine, and masked things that looked likely to be able to cause the problem.
For me, the following entry in packages.mask did the trick:

[colo-des]

I have encountered a similar problem when updating from mesa-23.0.3-1 to mesa-24.0.1-1 in my binary blfs using crux pkgutils.
In my case the X server was hung when starting from console and turned out to be the bug using the radoensi driver.

https://gitlab.freedesktop.org/mesa/mesa/-/issues/10648
https://gitlab.freedesktop.org/mesa/mesa/-/issues/10613#note_2290167
https://gitlab.archlinux.org/archlinux/packaging/packages/mesa/-/commit/43f45B0D68F5A6185005926EC16F70C50F39B0AA

Also had doubts about whether it was my update of the SPIRV-LLVM-Translator#17.0.0-1, but no, it has nothing to do with
the hanging X server.

[flexibeast]

[sam_]

[colo-des]

@sam_

My intention was to point out where the problem could be, since several days were trying that package was the culprit.
Until I found the patch "radeon_bo_can_reclaim_slab.diff" that solved the problem.
It is not in gentoo, is a blfs, in fact more than 3 months ago I do not update gentoo.
Well, the idea is that if you have a mesa-24 and the X server is hanged, you can try to apply that patch and see if you are lucky.

Greetings.

[ipic]

I am on media-libs/mesa-23.3.5 - which is Gentoo's current stable version.
dev-util/spirv-llvm-translator-17.0.0 Has been marked as stable in Gentoo.
My xfce4 installation is all current Gentoo stable packages.

So, with the current stable Gentoo packages, XFCE4 has a segmentation fault on startup, after the upgrade from dev-util/spirv-llvm-translator-16.0.0-r1 to dev-util/spirv-llvm-translator-17.0.0-r2
I believe that I have proved the issue is introduced with dev-util/spirv-llvm-translator-17.0.0-r2, because reverting it results in a working XFCE4 again.

Fingers are pointing to mesa, but I can't find squat about this problem (also, I probably suck at googling)

Give Gentoo STABLE has a hard issue, it seems a bit serious to me.

[sam_]

You could try apply that Mesa patch to see if it helps.

You could also try apply the changes after 17.0.0 from https://github.com/KhronosGroup/SPIRV-LLVM-Translator/commits/llvm_release_170/ as patches to spirv-llvm-translator, although none of them seem like obvious candidates so I wouldn't worry about trying it (would give more detailed instructions if it seemed likely to be successful but none of it looks relevant).

Once you've exhausted these avenues, you should file a Gentoo bug.

[ipic]

Thanks for the pointers.

Before doing that, I thought it would be worth seeing if the latest mesa fixes the problem.
I thus removed the package.mask for dev-util/spirv-llvm-translator-17.0.0 and added a package.accept_keywords entry for =media-libs/mesa-24.0.2

emerge @world

Result is that xfce4 now starts correctly, and everything works as far as I can see.

With that being the case, it seems to me that the Gentoo solution is to make media-libs/mesa-24.0.2 stable

Should I log a bug to that effect?

[sam_]

Could you try 23.3.6 too please?

[ipic]

Good call. I should have tried that first - doh.

Downgraded to media-libs/mesa-23.3.6 and xfce4 starts OK with that as well.

I'm going to stick with media-libs/mesa-24.0.2 because shiny

Both work with dev-util/spirv-llvm-translator-17.0.0-r2 installed

Gentoo solution would thus appear to be to promote media-libs/mesa-23.3.6 to stable, in favour of media-libs/mesa-23.3.5. The latter has a clear issue (at least on my build).

[sam_]

Thanks! Filed bug 926155.