I built Emacs 29.1 from source a few months ago and it was working pretty smoothly as far as I could tell – I was mainly using the elfeed-webkit package – until I tried to use it today and my Emacs session crashed. I was mainly using it in daemon mode, but evem just running emacs -Q and then M-x xwidget-webkit-browse-url RET wikipedia.org results in the error at the end of this post (sorry for the wall of text).

From the EmacsWiki and from reading /etc/PROBLEMS, I tried to use xwidgets-webkit again with SNAP=1 SNAP_NAME=1 SNAP_REVISION=1 emacs -Q, but it results in the same error.

It’s probably an issue with my system rather than Emacs – I’m running this on Manjaro Linux, and emacs-version gives:

GNU Emacs 29.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, cairo version 1.17.8) of 2023-08-28

What can I do to fix this?

(Below follows the error message referred to previously:)

Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want WebKit to use a different signal
X protocol error: GLXBadWindow on protocol request 152
Serial no: 9165

When compiled with GTK, Emacs cannot recover from X disconnects.
This is a GTK bug: https://gitlab.gnome.org/GNOME/gtk/issues/221
For details, see etc/PROBLEMS.
Fatal error 6: Aborted

(emacs:1651212): GLib-WARNING **: 19:56:32.608: g_main_context_prepare() called recursively from within a source's check() or prepare() member.

(emacs:1651212): GLib-WARNING **: 19:56:32.608: g_main_context_check() called recursively from within a source's check() or prepare() member.
Backtrace:
emacs(emacs_backtrace+0x53)[0x55895d109393]
emacs(terminate_due_to_signal+0xb1)[0x55895cf87759]
emacs(+0x8e777)[0x55895cf88777]
emacs(+0x1b5484)[0x55895d0af484]
emacs(+0x1b5564)[0x55895d0af564]
emacs(+0x1b583b)[0x55895d0af83b]
/usr/lib/libX11.so.6(_XError+0x11c)[0x7f99d59b374c]
/usr/lib/libX11.so.6(+0x44858)[0x7f99d59b3858]
/usr/lib/libX11.so.6(+0x44915)[0x7f99d59b3915]
/usr/lib/libX11.so.6(_XEventsQueued+0x5a)[0x7f99d59b39aa]
/usr/lib/libX11.so.6(XPending+0x58)[0x7f99d59a62c8]
/usr/lib/libgdk-3.so.0(+0x87a28)[0x7f99d618ea28]
/usr/lib/libglib-2.0.so.0(+0x5a40b)[0x7f99d5b2a40b]
/usr/lib/libglib-2.0.so.0(+0xb8099)[0x7f99d5b88099]
/usr/lib/libglib-2.0.so.0(g_main_context_pending+0x2d)[0x7f99d5b280ad]
/usr/lib/libgtk-3.so.0(gtk_events_pending+0x13)[0x7f99d63ecfe3]
emacs(+0x1a58bd)[0x55895d09f8bd]
emacs(gobble_input+0x109)[0x55895d0f57a9]
emacs(unblock_input+0x56)[0x55895d0f5be6]
emacs(Fmake_xwidget+0x467)[0x55895d223ed7]
/home/nonreligous/.emacs.d/eln-cache/29.1-b9da317a/xwidget-9ccb93b3-12fdd1c0.eln(F787769646765742d696e73657274_xwidget_insert_0+0x4d)[0x7f99a215a1cd]
emacs(funcall_subr+0x2a4)[0x55895d1912d4]
emacs(Ffuncall+0x10b)[0x55895d18efeb]
/home/nonreligous/.emacs.d/eln-cache/29.1-b9da317a/xwidget-9ccb93b3-12fdd1c0.eln(F787769646765742d7765626b69742d2d6372656174652d6e65772d73657373696f6e2d627566666572_xwidget_webkit__create_new_session_buffer_0+0x1d1)[0x7f99a215e971]
emacs(Ffuncall+0x10b)[0x55895d18efeb]
/home/nonreligous/.emacs.d/eln-cache/29.1-b9da317a/xwidget-9ccb93b3-12fdd1c0.eln(F787769646765742d7765626b69742d6e65772d73657373696f6e_xwidget_webkit_new_session_0+0x52)[0x7f99a215eae2]
emacs(Ffuncall+0x10b)[0x55895d18efeb]
/home/nonreligous/.emacs.d/eln-cache/29.1-b9da317a/xwidget-9ccb93b3-12fdd1c0.eln(F787769646765742d7765626b69742d676f746f2d75726c_xwidget_webkit_goto_url_0+0x106)[0x7f99a215f056]
emacs(Ffuncall+0x10b)[0x55895d18efeb]
/home/nonreligous/.emacs.d/eln-cache/29.1-b9da317a/xwidget-9ccb93b3-12fdd1c0.eln(F787769646765742d7765626b69742d62726f7773652d75726c_xwidget_webkit_browse_url_0+0x109)[0x7f99a215b2e9]
emacs(Ffuncall+0x10b)[0x55895d18efeb]
emacs(Ffuncall_interactively+0x37)[0x55895d187737]
emacs(Ffuncall+0x10b)[0x55895d18efeb]
emacs(Fapply+0x149)[0x55895d1918d9]
emacs(Fcall_interactively+0x45b)[0x55895d187bab]
/usr/bin/../lib/emacs/29.1/native-lisp/29.1-b9da317a/preloaded/simple-fab5b0cf-a050dc2b.eln(F636f6d6d616e642d65786563757465_command_execute_0+0x2b5)[0x7f99bc7cb975]
emacs(Ffuncall+0x10b)[0x55895d18efeb]
/usr/bin/../lib/emacs/29.1/native-lisp/29.1-b9da317a/preloaded/simple-fab5b0cf-a050dc2b.eln(F657865637574652d657874656e6465642d636f6d6d616e64_execute_extended_command_0+0x1e9)[0x7f99bc7ca649]
emacs(Ffuncall+0x10b)[0x55895d18efeb]
emacs(Ffuncall_interactively+0x37)[0x55895d187737]
emacs(Ffuncall+0x10b)[0x55895d18efeb]
...
[1]    1651212 IOT instruction (core dumped)  emacs -Q
  • Thaodan@alien.topBEnglish
    1·
    11 months ago

    Please use a pastebin to post the backtrace. Run thread apply all bt to get the backtrace from all threads.

  • cyneox@alien.topBEnglish
    1·
    11 months ago

    I can confirm this also happens on Arch Linux with latest updates (and emacs 29.x)

  • mac-230@alien.topBEnglish
    1·
    11 months ago

    I can confirm this also happens on emacs 30.0.5 on Ubuntu 22.04.3 as of a recent update. Webkit was working nicely before a security update and any calls to webkit now cause the emacs GUI to crash. Terminal emacs started with emacs -nw doesn’t crash but produces the error message: make-xwidget: GTK has not been initialized. It seems the issue is related to webkitgtk, as I have the same issue with emacs 28 and 29 loaded with or without my config. FWIW, the issue is, for me, not specific to elfeed-webkit, as something like:
    (xwidget-webkit-browse-url "https://google.com") also causes a crash.

    I’m not sure how to roll back webkitgtk to a previous version, but am wondering if that would fix the issue…

  • s930054123@alien.topBEnglish
    1·
    11 months ago

    I think the reason is that newer webkit version doesn’t support offscreen rendering, which emacs relied on. You can report a bug to emacs-devel and ask if the devs have plan for solving this.

    • nonreligious@alien.topOPBEnglish
      1·
      11 months ago

      I see. What’s the latest version of webkit that doesn’t have this problem? Have you been able to downgrade to it to verify?

      • s930054123@alien.topBEnglish
        1·
        11 months ago

        I don’t think the webkitgtk team would be willing to fix this, also it’s hard to explain the bizarre use case of Emacs to them.

        Well, Po Lu has another paragraph under the one you posted:

        WebKitGTK is not meant for displaying contents within programs that must display the same widget in more than one location; that is the metier of WPE (wpewebkit.org). Several months ago, I asked for interested individuals to step forth and undertake writing the code to replace WebKitGTK by that library, but was met with silence.

        Looks like the better way to fix this is to switch to the wpe library. Webkit is also quite buggy IMHO Ex: You cannot play video when using offscreen rendering, IOW visiting websites like youtube will hang infinitely. Currently no one is familiar with the xwidget-webkit codebase except Po Lu. I’m not sure if he has time and motivation to fix this. (Po Lu is also the Android Port maintainer…)