emacs 30.1 segfault on RHEL 9 in graphical launch with X forwarding #103
Comments
|
Thanks for reporting these issues - I think the native-compilation issue it is very likely the same as #96 - can you please try For the graphical segfault, I hope this is the same issue I am currently debugging in #101 which I hope to have a fix for soon. |
|
still occurs with latest/beta I can paste the stack trace, but a cursory examination suggests it's the same. |
|
Damn - thanks for confirming - if you could paste the full stack trace that would be good. Out of interest can you also run the following and paste the output: |
|
Beta stack trace: There is no Digging further, I can see (limited the search by trial and error) Looking at #96 |
|
Ah ok - so when I said to try the beta channel, I meant that it should fix the native-compilation error hopefully - but I realise the segfault will still be an issue - and I am currently trying to fix that as well - can you confirm that with the beta channel of the snap that the native-compilation errors are not appearing anymore? |
|
confirmed; the beta channel has no issues run |
|
Can you explain why it spontaneously started failing? Does snap auto-refresh in the background? Is there a way to fall back to what worked yesterday? |
|
Yes snaps auto refresh - apologies that this broke your setup - I am actively trying to get it fixed. In the meantime you can install the previous version using something like: |
|
I've spent the day fighting with snap because my
|
|
... sort of. The compile error is present in |
|
Again apologies for all the issues here - I think I have a fix for the segfault issue but am just doing some more testing on my end before I go ahead with it - thanks for your patience. |
alexmurray
added a commit
that referenced
this issue
Feb 27, 2025
Since the GTK version in the snap expects various gsettings schemas to be present we need to use the schemas shipped in the snap itself to avoid issues like #103 etc. Signed-off-by: Alex Murray <[email protected]>
|
I have just committed a fix and have triggered new builds of the snap which are available in the beta channel - if you can please test it that would be great, then I can promote it to the stable channel. |
alexmurray
added a commit
that referenced
this issue
Feb 27, 2025
As per https://docs.gtk.org/gio/overview.html#running-gio-applications it is GSETTINGS_SCHEMA_DIR not GSETTINGS_SCHEMAS_DIR 🤦♂️ - this should properly fix issue #103. Signed-off-by: Alex Murray <[email protected]>
|
Apologies - there was a typo in the fix - I just added another fix ontop which should actually fix it - this should be available in ~45 minutes in the beta channel for testing. |
|
Given the confirmation in #101 plus the validation I have done myself, I am going to promote this to the latest/stable channel - please let me know if you find any other issues. Thanks again for your patience. |
Sigh. Not quite. Noticing the GLX calls in the stack trace; this is an X-forwarded display RHEL 9 to MobaXterm. Maybe a path you didn't exercise yet? |
|
@jwmelto this sounds like a complicated setup - can you give me any pointers as to how I can recreate this in a local VM for testing? Can you also try running something for me: And post the output - I want to see if it is trying to load any libraries from the host system. Also do you by any chance have anything custom set in |
|
Sorry I should have been more specific - when you mentioned "this is an X-forwarded display RHEL 9 to MobaXterm" - this is the bit I meant was a complicated setup - if you are able to guide me through creating this in say a local VM that would be great. Otherwise I am not sure I will be able to debug / fix this. And it could well be that there is a chance in the X protocol or similar between what is in your setup and what the X libraries in emacs are expecting and so there may not be a way to fix this (since the snap is now using libraries from Ubuntu 24.04 which is a lot newer than RHEL 9) |
|
I'll be able to look into it tomorrow. The server runs RHEL 9. I access it from a PC running MobaXterm. One of the best features of this tool is the built-in X server. I connect to the RHEL server via SSH (with X forwarding). Normally, it works flawlessly. Now it doesn't. |
alexmurray
changed the title
|
|
Thanks - there doesn't appear to be anything particular revealing... any chance you could explain how I can set up a test VM to try and reproduce this myself? |
|
I'm not sure what to tell you. The headless server (running emacs snap) is running RHEL 9.4. It has an NVIDIA GPU, if that matters, but since the rendering is done remotely, I wouldn't expect so. You should be able to create a VM and SSH into it, but if possible I'd suggest it not be on the same physical box as your "remote" session, just to remove any possibility of optimizing out a relevant portion of the interaction. This doesn't seem very complicated to me. As noted, I connect using MobaXterm from a Windows PC, which automatically enables X forwarding. I've had no issue with X applications using this path on a variety of servers and OS's. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Running on RHEL 9; 30.1 installed.
After running flawlessly, this morning it stared segfault:
Running
-nwworks, but raises other errorsThe failure to invoke the gcc driver seems pretty important. Not finding libc is pretty bad too. Something changed, and I don't know what. I don't routinely do refreshes, but I removed and re-installed (no change). I tried
--channel=latest/edgeand no changeThe text was updated successfully, but these errors were encountered: