After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 637827 - vino crashes with > 1 screen
vino crashes with > 1 screen
Status: RESOLVED WONTFIX
Product: vino
Classification: Applications
Component: Server
2.32.x
Other Linux
: Normal critical
: ---
Assigned To: Vino Maintainer(s)
Vino Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2010-12-22 19:42 UTC by Brian J. Murrell
Modified: 2020-11-12 13:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gnome-remote-desktop repeating keystrokes (15.55 KB, image/png)
2020-11-12 13:18 UTC, Brian J. Murrell
Details

Description Brian J. Murrell 2010-12-22 19:42:45 UTC
As has been documented downstream in https://bugs.launchpad.net/ubuntu/+source/vino/+bug/682578, the vino server crashes when there is more than one screen on the machine, as returned by gdk_display_get_n_screens().

It seems it crashes because it tries to open the same port twice.
Comment 1 Amk 2011-06-09 08:51:58 UTC
I do not think it tries to open one port twice. the log shows it listening on two different ports. 

Running Gentoo, used vino-2.28.2, accessed one screen only, never tried the other.
After upgrade to vino-2.32.2, it fails to register GObject with DBusConnection:

09/06/2011 10:48:17 Listening IPv6://[::]:5900
09/06/2011 10:48:17 Listening IPv4://0.0.0.0:5900
09/06/2011 10:48:17 Autoprobing selected port 5900
09/06/2011 10:48:17 Advertising security type: 'TLS' (18)
09/06/2011 10:48:17 Advertising authentication type: 'No Authentication' (1)
09/06/2011 10:48:17 Advertising security type: 'No Authentication' (1)
09/06/2011 10:48:17 Autoprobing TCP port in (all) network interface
09/06/2011 10:48:17 Listening IPv6://[::]:5900
09/06/2011 10:48:17 Listening IPv4://0.0.0.0:5900
09/06/2011 10:48:17 Problems in NewSocketListenTCP()
09/06/2011 10:48:17 Listening IPv6://[::]:5901
09/06/2011 10:48:17 Listening IPv4://0.0.0.0:5901
09/06/2011 10:48:17 Autoprobing selected port 5901
09/06/2011 10:48:17 Advertising security type: 'TLS' (18)
09/06/2011 10:48:17 Advertising authentication type: 'No Authentication' (1)
09/06/2011 10:48:17 Advertising security type: 'No Authentication' (1)

** ERROR **: Failed to register GObject with DBusConnection
Comment 2 Brian J. Murrell 2011-08-08 01:46:50 UTC
Really?  Nothing?  Not even a triage of this issue?  It's been open nearly 8 months now.
Comment 3 David King 2011-08-08 07:28:28 UTC
I do not use multiple X screens, so this bug report could be difficult for me to reproduce. However, the root cause seems to be trying to register a D-Bus object twice. There are likely assumptions made by Vino that are not valid when two X screens are used. Assuming that there is only one X screen could be a workaround, but it is probably better to come up with a fic instead.

In Vino 3.0.0, the D-Bus handling was rewritten by Ryan Lortie to use GDBus, so this bug might be fixed in that or newer versions. Please test that, and if there is still a problem, please provide a stack trace (with debug symbols, as described at http://live.gnome.org/GettingTraces) of the crash.
Comment 4 Brian J. Murrell 2011-08-08 11:39:56 UTC
The problem with trying to use Vino 3.0.0 is that that likely requires Gnome 3.0, yes?

I am not using Gnome 3.0 (and likely won't be for some time, if at all -- it will depend on whether the shortcomings are addressed in future versions or not) due to it's numerous short-comings (compared to Gnome 2.32 for example).  I'd really like to see this fixed in Vino 2.32.x since that's that last available version for a usable Gnome.

  • #0 __kernel_vsyscall
  • #1 raise
    at ../nptl/sysdeps/unix/sysv/linux/raise.c line 64
  • #2 abort
    at abort.c line 92
  • #3 g_logv
    at /build/buildd/glib2.0-2.28.6/./glib/gmessages.c line 557
  • #4 g_log
    at /build/buildd/glib2.0-2.28.6/./glib/gmessages.c line 577
  • #5 dbus_g_connection_register_g_object
    at dbus-gobject.c line 2590
  • #6 tp_dbus_daemon_register_object
    from /usr/lib/libtelepathy-glib.so.0
  • #7 tp_base_client_register
    from /usr/lib/libtelepathy-glib.so.0
  • #8 ??
  • #9 g_type_create_instance
    at /build/buildd/glib2.0-2.28.6/./gobject/gtype.c line 1889
  • #10 g_object_constructor
    at /build/buildd/glib2.0-2.28.6/./gobject/gobject.c line 1615
  • #11 g_object_newv
    at /build/buildd/glib2.0-2.28.6/./gobject/gobject.c line 1398
  • #12 g_object_new
    at /build/buildd/glib2.0-2.28.6/./gobject/gobject.c line 1308
  • #13 ??
  • #14 ??
  • #15 g_type_create_instance
    at /build/buildd/glib2.0-2.28.6/./gobject/gtype.c line 1889
  • #16 g_object_constructor
    at /build/buildd/glib2.0-2.28.6/./gobject/gobject.c line 1615
  • #17 g_object_newv
    at /build/buildd/glib2.0-2.28.6/./gobject/gobject.c line 1479
  • #18 g_object_new_valist
    at /build/buildd/glib2.0-2.28.6/./gobject/gobject.c line 1596
  • #19 g_object_new
    at /build/buildd/glib2.0-2.28.6/./gobject/gobject.c line 1311
  • #20 ??
  • #21 ??
  • #22 g_object_newv
    at /build/buildd/glib2.0-2.28.6/./gobject/gobject.c line 1507
  • #23 g_object_new_valist
    at /build/buildd/glib2.0-2.28.6/./gobject/gobject.c line 1596
  • #24 g_object_new
    at /build/buildd/glib2.0-2.28.6/./gobject/gobject.c line 1311
  • #25 ??
  • #26 ??
  • #27 __libc_start_main
    at libc-start.c line 226
  • #28 ??

Comment 5 David King 2011-08-08 13:06:41 UTC
It seems that the Vino debug symbols are missing from the stack trace, although I can see that the crash occurs after connection to Telepathy. Please install the necessary debug symbols and post an updated trace.

Vino 3.0.3 requires GTK+ 3, for GtkApplication and the preferences dialog, but otherwise nothing particularly tied to GNOME 3.0. AS GTK+ 3 can be installed in parallel with GTK+ 2, it is relatively simple to use Vino 3 on a predominantly GTK+ 2 system.
Comment 6 Brian J. Murrell 2011-08-08 13:14:38 UTC
Ahhh.  Sorry 'bout that.  This one should have them, and the libtelepathy-glib0 symbols for good measure.

  • #0 __kernel_vsyscall
  • #1 raise
    at ../nptl/sysdeps/unix/sysv/linux/raise.c line 64
  • #2 abort
    at abort.c line 92
  • #3 g_logv
    at /build/buildd/glib2.0-2.28.6/./glib/gmessages.c line 557
  • #4 g_log
    at /build/buildd/glib2.0-2.28.6/./glib/gmessages.c line 577
  • #5 dbus_g_connection_register_g_object
    at dbus-gobject.c line 2590
  • #6 tp_dbus_daemon_register_object
    at dbus-daemon.c line 930
  • #7 tp_base_client_register
    at base-client.c line 830
  • #8 vino_tube_servers_manager_init
    at vino-tube-servers-manager.c line 119
  • #9 g_type_create_instance
    at /build/buildd/glib2.0-2.28.6/./gobject/gtype.c line 1889
  • #10 g_object_constructor
    at /build/buildd/glib2.0-2.28.6/./gobject/gobject.c line 1615
  • #11 g_object_newv
    at /build/buildd/glib2.0-2.28.6/./gobject/gobject.c line 1398
  • #12 g_object_new
    at /build/buildd/glib2.0-2.28.6/./gobject/gobject.c line 1308
  • #13 vino_tube_servers_manager_new
    at vino-tube-servers-manager.c line 139
  • #14 vino_dbus_listener_init
    at vino-dbus-listener.c line 248
  • #15 g_type_create_instance
    at /build/buildd/glib2.0-2.28.6/./gobject/gtype.c line 1889
  • #16 g_object_constructor
    at /build/buildd/glib2.0-2.28.6/./gobject/gobject.c line 1615
  • #17 g_object_newv
    at /build/buildd/glib2.0-2.28.6/./gobject/gobject.c line 1479
  • #18 g_object_new_valist
    at /build/buildd/glib2.0-2.28.6/./gobject/gobject.c line 1596
  • #19 g_object_new
    at /build/buildd/glib2.0-2.28.6/./gobject/gobject.c line 1311
  • #20 vino_dbus_listener_new
    at vino-dbus-listener.c line 293
  • #21 vino_server_constructed
    at vino-server.c line 1315
  • #22 g_object_newv
    at /build/buildd/glib2.0-2.28.6/./gobject/gobject.c line 1507
  • #23 g_object_new_valist
    at /build/buildd/glib2.0-2.28.6/./gobject/gobject.c line 1596
  • #24 g_object_new
    at /build/buildd/glib2.0-2.28.6/./gobject/gobject.c line 1311
  • #25 vino_prefs_create_server
    at vino-prefs.c line 517
  • #26 main
    at vino-main.c line 117

Comment 7 André Klapper 2020-11-12 12:24:39 UTC
Vino is not under active development anymore and unmaintained.

Please use gnome-remote-desktop instead.

Closing this report as WONTFIX to reflect reality.
Comment 8 Brian J. Murrell 2020-11-12 13:18:31 UTC
Created attachment 374303 [details]
gnome-remote-desktop repeating keystrokes
Comment 9 Brian J. Murrell 2020-11-12 13:19:58 UTC
Only 10 years after opening this ticket, however...

(In reply to André Klapper from comment #7)
> Vino is not under active development anymore and unmaintained.
> 
> Please use gnome-remote-desktop instead.

Does that work with Xorg?  Wayland is an non-starter for any number of reasons. 
No soft-kvm is one:

https://github.com/debauchee/barrier/issues/109

But the main one is really that gnome-remote-desktop and pipewire performance sucks.  Really badly:

https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues/32

https://www.reddit.com/r/gnome/comments/hr5gme/gnomeremotedesktop_absolutely_hammers_my_cpu/

And that's when it somewhat works.  As of late, I only ever seem to get a black screen from it.

I also often suffer multiple keystroke sends.  That's where I press a key once but it gets received numerous times.  See the attachment https://bug637827.bugzilla-attachments.gnome.org/attachment.cgi?id=374303.
Comment 10 André Klapper 2020-11-12 13:24:40 UTC
This ticket is about vino, it is not about gnome-remote-desktop.

Please ask general questions in a support forum. Thanks for your understanding.
Comment 11 Brian J. Murrell 2020-11-12 13:30:57 UTC
Yes, and my response was about vino.  Specifically if vino has been discontinued before it's replacement is actually up to the task of, well, actually replacing it.

And you didn't even answer the first question.  Does gnome-remote-desktop work with Xorg, as vino did.  See it's still about vino.
Comment 12 André Klapper 2020-11-12 13:49:16 UTC
Yes, as this is not a place for general questions but an issue tracker. 
See my previous comment.
Comment 13 André Klapper 2020-11-12 13:55:16 UTC
I am a messenger. I am not a gnome-remote-desktop developer who might not want to waste years working around the limitations of the ancient Xorg architecture.
Nobody can stop you from continuing to use Vino with all its security issues and limitations; I merely communicated that Vino will not see any further development. 
Thanks for understanding that. :)