Bug 1349412

rebuild with --with-x-toolkit=gtk2 --without-xwidgets fixes this (so far)

Yep, I get this as well, and emacs prints this to stderr:

X protocol error: BadRequest (invalid request code or no such operation) on protocol request 131
When compiled with GTK, Emacs cannot recover from X disconnects.
This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715
For details, see etc/PROBLEMS.
Fatal error 6: Aborted

It actually bring up emacs OK, but as soon as I move the mouse into it (I have focus follows mouse), it crashes.

I rebuilt emacs with the options from comment #1 and it is working fine for me now inside an x2go session (thanks for the info!).

If I understand what comment #1 is saying, you are only working around the crash by building a version of emacs that can recover from it.  I really don't want to be in the position of having to maintain my own version of emacs.  My question is, what is causing the crash, i.e. why does emacs hit an X protocol error BadRequest when running in a remote desktop environment?

This happens not only with x2go but also with VNC and NX sessions.  Some other X applications are crashing too.  This does not happen in a console login.  (I upgraded the remote system recently directly from Fedora 22 to 24, and I am wondering whether something did not get upgraded correctly.)

I suspect it is some X extension that isn't provided by the X server on the remote desktop software (but which GTK3 insists on using). Here's a comparison of the X extensions that show up on my desktop at work versus over an x2go session to my home system:

Composite
        DEC-XTRAP
DRI2
        Extended-Visual-Information
Generic Event Extension
MIT-SCREEN-SAVER
        MIT-SUNDRY-NONSTANDARD
NV-CONTROL
NV-GLX
Present
        SECURITY
        SGI-GLX
        TOG-CUP
        XC-APPGROUP
XFIXES
        XFree86-Bigfont
XFree86-DGA
XFree86-VidModeExtension

The names on the left are on my desktop but not x2go and the names on the right are on x2go, but not my desktop.

If I was going to guess, I'd pick Composite or DRI2 as the culprits.

(In reply to Robert K. Moniot from comment #4)
> If I understand what comment #1 is saying, you are only working around the
> crash by building a version of emacs that can recover from it.  I really
> don't want to be in the position of having to maintain my own version of
> emacs.  My question is, what is causing the crash, i.e. why does emacs hit
> an X protocol error BadRequest when running in a remote desktop environment?
> 
> This happens not only with x2go but also with VNC and NX sessions.  Some
> other X applications are crashing too.  This does not happen in a console
> login.  (I upgraded the remote system recently directly from Fedora 22 to
> 24, and I am wondering whether something did not get upgraded correctly.)

I was able to test x2go on a system that was freshly installed with F24 from scratch.  Same protocol error, so it is not something missed in the upgrade.

(In reply to Tom Horsley from comment #5)
> I suspect it is some X extension that isn't provided by the X server on the
> remote desktop software (but which GTK3 insists on using). Here's a
> comparison of the X extensions that show up on my desktop at work versus
> over an x2go session to my home system:
> 
> Composite
>         DEC-XTRAP
> DRI2
>         Extended-Visual-Information
> Generic Event Extension
> MIT-SCREEN-SAVER
>         MIT-SUNDRY-NONSTANDARD
> NV-CONTROL
> NV-GLX
> Present
>         SECURITY
>         SGI-GLX
>         TOG-CUP
>         XC-APPGROUP
> XFIXES
>         XFree86-Bigfont
> XFree86-DGA
> XFree86-VidModeExtension
> 
> The names on the left are on my desktop but not x2go and the names on the
> right are on x2go, but not my desktop.
> 
> If I was going to guess, I'd pick Composite or DRI2 as the culprits.

Thanks.  I tend to agree with your suspicion.  x2go uses the NX libraries, and these may be out of sync with Fedora 24.  (Note I do not see this problem when connecting to a Fedora 22 remote system.)

I doubt it is the NX libraries as much as it is GTK3 as the gnome developers never saw a new feature they didn't want to depend on :-).

May be worth mentioning that xemacs does not suffer from this problem.  Unfortunately, it's xemacs, not standard emacs.  It barfed when trying to import my .emacs customizations, so need to re-create those.

I get this problem too.

Here is a stacktrace:

(gdb) bt
#0  0x00007fffef21ab09 in raise () at /lib64/libpthread.so.0
#1  0x00000000004e8301 in terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=40) at emacs.c:391
#2  0x0000000000500c63 in emacs_abort () at sysdep.c:2328
#3  0x00000000004ba0a6 in x_connection_closed (dpy=dpy@entry=0x155ec00, error_message=<optimized out>, error_message@entry=0x7fffffffb560 "X protocol error: BadRequest (invalid request code or no such operation) on protocol request 131", ioerror=ioerror@entry=false) at xterm.c:9459
#4  0x00000000004be5a0 in x_error_quitter (display=0x155ec00, event=<optimized out>, event=<optimized out>) at xterm.c:9547
#5  0x00000000004be61b in x_error_handler (display=0x155ec00, event=0x7fffffffb720) at xterm.c:9517
#6  0x00007ffff471b57d in _XError () at /lib64/libX11.so.6
#7  0x00007ffff47183e7 in handle_error () at /lib64/libX11.so.6
#8  0x00007ffff47184ad in handle_response () at /lib64/libX11.so.6
#9  0x00007ffff4719478 in _XReply () at /lib64/libX11.so.6
#10 0x00007ffff470f351 in XQueryPointer () at /lib64/libX11.so.6
#11 0x00007ffff6745aca in gdk_x11_device_core_query_state () at /lib64/libgdk-3.so.0
#12 0x00007ffff67626a5 in gdk_window_x11_get_device_state () at /lib64/libgdk-3.so.0
#13 0x00007ffff6738dbb in gdk_window_get_device_position_double () at /lib64/libgdk-3.so.0
#14 0x00007ffff6738ebd in gdk_window_get_device_position () at /lib64/libgdk-3.so.0
#15 0x00007ffff6cf09d9 in gtk_tooltip_show_tooltip () at /lib64/libgtk-3.so.0
#16 0x00007ffff6cf0f34 in tooltip_popup_timeout () at /lib64/libgtk-3.so.0
#17 0x00007ffff671d418 in gdk_threads_dispatch () at /lib64/libgdk-3.so.0
#18 0x00007ffff5088173 in g_timeout_dispatch () at /lib64/libglib-2.0.so.0
#19 0x00007ffff5087703 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#20 0x00000000005c9f68 in xg_select (fds_lim=<optimized out>, rfds=rfds@entry=0x7fffffffc360, wfds=wfds@entry=0x0, efds=efds@entry=0x0, timeout=<optimized out>, sigmask=sigmask@entry=0x0) at xgselect.c:158
#21 0x0000000000468a18 in x_menu_wait_for_event (data=data@entry=0x0) at xmenu.c:196
#22 0x0000000000469e4f in xw_popup_dialog (do_timers=true, widget=0x73463a0) at xmenu.c:393
#23 0x0000000000469e4f in xw_popup_dialog (first_wv=<optimized out>, f=0x12b5260) at xmenu.c:1695
#24 0x0000000000469e4f in xw_popup_dialog (title=<optimized out>, error_name=<synthetic pointer>, header=0, f=0x12b5260) at xmenu.c:1883
#25 0x0000000000469e4f in xw_popup_dialog (f=0x12b5260, header=0, contents=<optimized out>) at xmenu.c:1946
#26 0x000000000055884b in Ffuncall (nargs=3, args=args@entry=0x7fffffffc560) at eval.c:2721
#27 0x000000000058b8d3 in exec_byte_code (bytestr=<optimized out>, vector=8815861, maxdepth=<optimized out>, args_template=<optimized out>, nargs=nargs@entry=1, args=<optimized out>, args@entry=0x8684f0 <pure+129680>) at bytecode.c:639
#28 0x0000000000558386 in funcall_lambda (fun=281474985526437, nargs=nargs@entry=1, arg_vector=0x8684f0 <pure+129680>, arg_vector@entry=0x7fffffffc878) at eval.c:2876
#29 0x000000000055866b in Ffuncall (nargs=2, args=args@entry=0x7fffffffc870) at eval.c:2775
#30 0x000000000058b8d3 in exec_byte_code (bytestr=<optimized out>, vector=85555221, maxdepth=<optimized out>, args_template=<optimized out>, nargs=nargs@entry=0, args=<optimized out>, args@entry=0x5197810) at bytecode.c:639
#31 0x0000000000558386 in funcall_lambda (fun=562950038977101, nargs=nargs@entry=0, arg_vector=0x5197810, arg_vector@entry=0x7fffffffcb90) at eval.c:2876
#32 0x000000000055866b in Ffuncall (nargs=1, args=args@entry=0x7fffffffcb88) at eval.c:2775
#33 0x000000000058b8d3 in exec_byte_code (bytestr=<optimized out>, vector=85558533, maxdepth=<optimized out>, args_template=<optimized out>, nargs=nargs@entry=0, args=<optimized out>, args@entry=0x5198500) at bytecode.c:639
#34 0x0000000000558386 in funcall_lambda (fun=281475062269261, nargs=nargs@entry=0, arg_vector=0x5198500, arg_vector@entry=0x7fffffffcd80) at eval.c:2876
#35 0x000000000055866b in Ffuncall (nargs=1, args=0x7fffffffcd78) at eval.c:2775
#36 0x00000000005588c9 in funcall_nil (nargs=<optimized out>, args=<optimized out>) at eval.c:2353
#37 0x0000000000556a0c in run_hook_with_args (nargs=1, args=0x7fffffffcd78, funcall=0x5588c0 <funcall_nil>) at eval.c:2530
#38 0x0000000000556bf4 in Frun_hooks (funcall=<optimized out>, args=<optimized out>, nargs=<optimized out>) at eval.c:2376
#39 0x0000000000556bf4 in Frun_hooks (args=0x7fffffffcd78, nargs=1) at eval.c:2395
#40 0x0000000000556bf4 in Frun_hooks (hook=<optimized out>) at eval.c:2543
#41 0x0000000000556bf4 in Frun_hooks (nargs=2, args=0x7fffffffce40) at eval.c:2377
#42 0x0000000000558759 in Ffuncall (nargs=3, args=args@entry=0x7fffffffce38) at eval.c:2694
#43 0x000000000058b8d3 in exec_byte_code (bytestr=<optimized out>, vector=9962389, maxdepth=<optimized out>, args_template=<optimized out>, nargs=nargs@entry=0, args=<optimized out>, args@entry=0x980390 <pure+1276208>) at bytecode.c:639
#44 0x0000000000558386 in funcall_lambda (fun=562949963383621, nargs=nargs@entry=0, arg_vector=0x980390 <pure+1276208>, arg_vector@entry=0x7fffffffd728) at eval.c:2876
#45 0x000000000055866b in Ffuncall (nargs=1, args=args@entry=0x7fffffffd720) at eval.c:2775
#46 0x000000000058b8d3 in exec_byte_code (bytestr=<optimized out>, vector=9958429, maxdepth=<optimized out>, args_template=<optimized out>, nargs=nargs@entry=0, args=<optimized out>, args@entry=0x97f418 <pure+1272248>) at bytecode.c:639
#47 0x0000000000558386 in funcall_lambda (fun=11540474055095245, fun@entry=9958349, nargs=nargs@entry=0, arg_vector=0x97f418 <pure+1272248>, arg_vector@entry=0x7fffffffda00) at eval.c:2876
#48 0x0000000000557740 in apply_lambda (fun=9958349, args=<optimized out>, count=count@entry=4) at eval.c:2815
#49 0x0000000000557a6f in eval_sub (form=form@entry=17979747) at eval.c:2262
#50 0x000000000055b33c in Feval (form=17979747, lexical=<optimized out>) at eval.c:2009
#51 0x0000000000556fa2 in internal_condition_case (bfun=bfun@entry=0x4e8700 <top_level_2>, handlers=handlers@entry=19488, hfun=hfun@entry=0x4ed040 <cmd_error>) at eval.c:1313
#52 0x00000000004ead9c in top_level_1 (ignore=ignore@entry=0) at keyboard.c:1129
#53 0x0000000000556f43 in internal_catch (tag=tag@entry=46416, func=func@entry=0x4ead40 <top_level_1>, arg=arg@entry=0) at eval.c:1079
#54 0x00000000004e8698 in command_loop () at keyboard.c:1090
#55 0x00000000004ecc47 in recursive_edit_1 () at keyboard.c:697
#56 0x00000000004ecf88 in Frecursive_edit () at keyboard.c:768
#57 0x0000000000416ffd in main (argc=1, argv=0x7fffffffdd78) at emacs.c:1658
(gdb) quit

*** Bug 1370280 has been marked as a duplicate of this bug. ***

confirmed on my system as well.
Running Fedora 24 on client and server side.
Then starting an xfce sessing through x2go on the client.
Emacs in its own window crashes within a few seconds (scrolling in the window actually makes it crash even sooner).
My workaround for now is to run emacs in text mode in a terminal, but a proper fix would be very welcome.

This page:

https://devtalk.nvidia.com/default/topic/952373/linux/367-35-driver-fedora-24-glx-segmentation-faults/

suggests that there should be a file /etc/x2go/x2goagent.options
in which a line like this:

X2GO_NXAGENT_DEFAULT_OPTIONS+=" -extension GLX"

can be disabled as workaround for some gtk issues.

Did anyone try this?
Unfortunately I have no root account on the machine running the server, so I can not easily test this myself.

There already is no GLX under x2go (glxinfo, for example, just gives an error). The problem is gtk3 randomly depends on having GL (some gtk3 programs happen to go through a path that doesn't depend on GL, and they work, other gtk3 programs always barf).

Recently (see bug 1395366), the dependence on GL has moved into libepoxy and happens really early during init in every gtk3 program, so now they all segfault trying to scan strings that are NULL pointers, not strings. (I patched my local libepoxy to all NULL pointer checks, and can now get back to the original crash rather than a much earlier segfault :-).

I've seen reports that if you go to the trouble to get virtualGL configured correctly, you can make gtk3 happy all the time, but it seems complicated to get right, and I haven't tried it yet.

mmm, glxinfo seems to run on my side, if I launch it from a terminal inside x2go running xfce. I get a lot of textual output and no errors. Also glxgears seems to run, although slowly.

(In reply to Jos de Kloe from comment #13)

> X2GO_NXAGENT_DEFAULT_OPTIONS+=" -extension GLX"
> 
> can be disabled as workaround for some gtk issues.
> 
> Did anyone try this?
> Unfortunately I have no root account on the machine running the server, so I
> can not easily test this myself.

I tried it but emacs still crashes.

This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

On Fedora 26 crash is reproducable with emacs-25.2-3.fc26.x86_64

As a workaround, you can now use emacs built with LUCID framework instead of GTK, I think that should help (package emacs-lucid).

thanks for your suggestion. However no emacs-lucid package seems to exist in the default fedora repository. Where is it available?

Check Bug #1471258

The package is in the testing repository for Fedora 24 and 26.

Of course I meant Fedora 25 and 26

are you sure? It is not in the output of
  dnf list --enablerepo="*testing"
on my f26 system.

Yes, for Fedora 26 it is in the stable repository for Fedora 25 in testing.

I tried emacs-lucid under a x2go session talking to my fedora 26 system at work and it does indeed startup and function without crashing. It only took an hour or so to find out how to run the alternatives command to make emacs-lucid the default :-).

alternatives --config emacs

Pick the number for emacs-lucid.

You can get the packages from https://koji.fedoraproject.org/koji/buildinfo?buildID=919405 if the dnf method still doesn't work for some reason.

thanks, the package appeared in the regular repository now. I guess I have been suffering from an unusually slow mirror.

Anyway, I can confirm that emacs-lucid works well for me in the x2go environment.

Still I hope emacs will be fixed at some point in the near future.

Add a me too, WRT emacs

I'm having the same problem (x2go with emacs and gtk3) under CentOS 7.  I've created a modified SPEC file that, in addition to the other emacs packages, also builds an "emacs-gtk2" package.  The file is here if anybody wants it:

https://pastebin.com/raw/GhYa050t

Notice that I've hacked the "Release" line to give the packages
the same name as my already-installed emacs packages.  This was so
I could just install the new emacs-gtk package, satisfying its dependencies, without re-installing the other packages.  To undo this hack, just un-comment the original Release line and comment out my bogus one.

This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26
is no longer maintained, which means that it will not receive any
further security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

for information only:
the problem seems to be solved for me now, running Fedora 28 on both server and clients side.

For the record, perhaps this is a duplicate of bug 1483942 (which was fixed)?

Yes, it seems like it.

I agree that in Fedora 28 the bug is fixed.