Bug 1349412 - crash when run through x2go
Summary: crash when run through x2go
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: emacs
Version: 26
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jan Synacek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1370280 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-06-23 12:35 UTC by Neal Becker
Modified: 2018-08-27 13:14 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-29 11:52:57 UTC
Type: Bug


Attachments (Terms of Use)

Description Neal Becker 2016-06-23 12:35:04 UTC
Description of problem:
https://retrace.fedoraproject.org/faf/reports/1178478/

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Neal Becker 2016-06-23 13:22:39 UTC
rebuild with --with-x-toolkit=gtk2 --without-xwidgets fixes this (so far)

Comment 2 Tom Horsley 2016-06-27 13:32:06 UTC
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.

Comment 3 Tom Horsley 2016-06-28 13:21:15 UTC
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!).

Comment 4 Robert K. Moniot 2016-07-26 18:39:51 UTC
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.)

Comment 5 Tom Horsley 2016-07-26 19:14:02 UTC
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.

Comment 6 Robert K. Moniot 2016-07-26 19:27:55 UTC
(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.

Comment 7 Robert K. Moniot 2016-07-26 19:32:40 UTC
(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.)

Comment 8 Tom Horsley 2016-07-26 19:47:18 UTC
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 :-).

Comment 9 Robert K. Moniot 2016-08-12 14:54:11 UTC
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.

Comment 10 Joakim Verona 2016-08-21 14:19:30 UTC
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

Comment 11 Jan Synacek 2016-08-30 08:46:59 UTC
*** Bug 1370280 has been marked as a duplicate of this bug. ***

Comment 12 Jos de Kloe 2016-11-03 15:10:52 UTC
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.

Comment 13 Jos de Kloe 2016-11-17 11:14:49 UTC
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.

Comment 14 Tom Horsley 2016-11-17 12:41:16 UTC
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.

Comment 15 Jos de Kloe 2017-02-09 10:37:02 UTC
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.

Comment 16 JM 2017-03-13 23:14:00 UTC
(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.

Comment 17 Fedora End Of Life 2017-07-25 21:14:42 UTC
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.

Comment 18 René Genz 2017-07-26 20:38:32 UTC
On Fedora 26 crash is reproducable with emacs-25.2-3.fc26.x86_64

Comment 19 Jan Synacek 2017-07-27 05:46:21 UTC
As a workaround, you can now use emacs built with LUCID framework instead of GTK, I think that should help (package emacs-lucid).

Comment 20 Jos de Kloe 2017-07-29 14:51:01 UTC
thanks for your suggestion. However no emacs-lucid package seems to exist in the default fedora repository. Where is it available?

Comment 21 JM 2017-07-29 14:59:01 UTC
Check Bug #1471258

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

Comment 22 JM 2017-07-29 15:00:04 UTC
Of course I meant Fedora 25 and 26

Comment 23 Jos de Kloe 2017-07-29 15:51:45 UTC
are you sure? It is not in the output of
  dnf list --enablerepo="*testing"
on my f26 system.

Comment 24 JM 2017-07-29 16:01:43 UTC
Yes, for Fedora 26 it is in the stable repository for Fedora 25 in testing.

Comment 25 Tom Horsley 2017-07-30 19:14:04 UTC
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.

Comment 26 Jan Synacek 2017-07-31 06:07:54 UTC
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.

Comment 27 Jos de Kloe 2017-08-10 18:13:55 UTC
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.

Comment 28 Graeme Vetterlein 2017-11-15 19:30:33 UTC
Add a me too, WRT emacs

Comment 29 Bryan Wright 2018-04-09 18:52:57 UTC
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.

Comment 30 Fedora End Of Life 2018-05-03 08:39:45 UTC
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.

Comment 31 Fedora End Of Life 2018-05-29 11:52:57 UTC
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.

Comment 32 Jos de Kloe 2018-06-30 14:08:29 UTC
for information only:
the problem seems to be solved for me now, running Fedora 28 on both server and clients side.

Comment 33 Glenn Morris 2018-08-24 18:17:25 UTC
For the record, perhaps this is a duplicate of bug 1483942 (which was fixed)?

Comment 34 Jan Synacek 2018-08-27 08:08:44 UTC
Yes, it seems like it.

Comment 35 Robert K. Moniot 2018-08-27 13:14:51 UTC
I agree that in Fedora 28 the bug is fixed.


Note You need to log in before you can comment on or make changes to this bug.