[apport] vino-server crashed with SIGSEGV in g_type_check_class_cast()

I can't see on your screenshot the vino icon, on notification area. Where is it?

Is nx server running on the same host you're trying to access? If so, try to disable it.

@John Wendell

Your remark made me test the following:

When I try to connect to the remote vnc server, I get a "connection refused" error, unless there is a connection established with nx.

Further, on the vnc screen, I have the same as on the nx screen, which makes me wonder whether the remote computer has automatically logged in into a gnome session!?

The problem might have originated doing the following: during the last update, gdm was also updated and I was asked whether I wanted to keep my old gdm-config-file or whether the new version should be installed. I chose to keep the old.

I am trying to determine whether the computer automatically logs into the user account when it starts.

There are several xfce processes running when I enter per ssh and ask the process list.

So, I assume that the xfce desktop is running and therefore I cannot connect to the vino server.

I have to find out, have to make gnome start instead of xfce...

I think this bug report can be closed depending on vinos functionality:

Here is probably what happened:

- Somehow I set it to boot automatically into xfce instead of gnome (as the computer is headless, it took me a while to figure it out)

- Consequently, vnc did only connect to a gnome session if I opened one remotely through nx (otherwise there was no gnome session running, which one could connect to); thus
-- if vino is meant to only connect to the gnome session that has been opened localy, the bug can be closed unless one wants to refine it, so that it does not try to forward other sessions
-- if vino should also forward gnome sessions that have been opened from a remote computer, there is a bug in vino because it is under this situation that the problems arise,

I have in the meantime managed to make the headless computer again automatically open a gnome session when it is started, and under this situation vino behaves properly.

Sorry if I made you waste your time...

StacktraceTop:IA__g_type_check_class_cast (type_class=0x80e3950, is_a_type=80) at gtype.c:3182
vino_status_icon_finalize (object=0x80e4018) at vino-status-icon.c:88
IA__g_object_unref (_object=0x80e4018) at gobject.c:1788
vino_server_handle_client_gone (rfb_client=0x80dac00) at vino-server.c:141
rfbClientConnectionGone (cl=0x80dac00) at rfbserver.c:320

Hi. Could you help us with this bug? If so:

1) When you connect on machine, do you see any icon on notification area?

2) Could you run vino-server with valgrind tool? If so:

 - Install valgrind package

 - Run in a terminal:
  - gconftool-2 -s /desktop/gnome/remote_access/enabled -t bool false
  - killall -9 vino-server
  - valgrind --tool=memcheck --leak-check=yes /usr/lib/vino/vino-server

 - In another terminal:
  - gconftool-2 -s /desktop/gnome/remote_access/enabled -t bool true

- At this point, vino is enabled and running, try to reproduce this bug

- Attach here all output generated in terminal

Hello,

As you know, the problem occurred while the remote headless computer
was set to automatically login into an xfce session. When I tried to
connect with vnc to what I thought was a gnome session, it did not
connect, unless a nx gnome session was also running, in which case
the image in the vnc client was not clear.

Somehow I managed to make the remote headless computer automatically
login into a gnome session and the problem does not occur anymore.

Unfortunately I don't know how I can make the remote headless
computer automatically login into the xfce session. I tried
forwarding gdmsetup by ssh -Y, but the changes that I make in the
forwarded "Login Window", particularly the Default Session popup,
seem not to be effective when it automatically logs in.

Could you please tell me how I can make it automatically boot into an
xfce session, so that I can try to reproduce the problem and give you
the output you asked for.

francesco

The configuration to use is written to the user .dmrc

I replaced gnome with xfce in the .dmrc file in my home folder. Gnome did not start automatically; xfce did not start either (but I am not sure, because the system is headless.

I tried what you said in 2 manners:

1. Opened gnome session with nx and connected also remotely with ssh, through which I started valgrind. Then I tried to connected with vnc and got the image of the gnome nx session. However, the image was a bit screwed up and it was frozen; it did not respond to movements and clicks of the mouse. You can find the output in the valgrind_ssh_output.txt file.

2. I launched valgrind in a terminal that resided in the nx gnome session. Then I tried to open the vnc session. When valgrind was running, I did not get the image of the gnome nx session through vnc; but when valgrind was not running, the image of the gnome nx session was forwarded through vnc; like previously, the image was not clear and vnc was frozen. You can find the output of valgrind in the valgrind_nx_output.txt file.

could you get a valgrind log with vino-dbgsym installed?

vino-dbgsym is not in my feisty repos

Could you please tell me in what repo I can find it?

you can read https://wiki.ubuntu.com/DebuggingProgramCrash about that

Here are the outputs of valgrind with vino-dbgsym installed.

Like previously, launched valgrind in two ways:

1. When I launch valgrind in a terminal in the forwarded nx gnome session, I don't get the desktop through vnc, but it tells me that the connection has been closed by peer.

2. When I launch valgrind in a terminal that I connect through ssh to ubuntu, the already opened gnome nx session gets also forwarded through vnc. But the vnc image has lines as in my screenshot above and is frozen. (The forwarded pointer only moved once.) Then, the vnc window closes with a lost connection error and when I try to reconnect, I get a connection closed by peer error.

Francesco, could we chat? Add me on jabber/msn.

Here what i did:

1) Installed NX server
2) Restarted machine
3) I did not login
4) From a windows machine in the network, i logged in via NX client into a gnome session
5) From that session, enabled vino in System->Preferences->Remote Desktop
6) From another network machine, i connected via VNC without problems
7) Everything worked as expected

As you can see, i couldn't reproduce this bug...

You are doing these same steps, right?

Hello Jonh Wendell,

Your steps are roughly the same, but here is exactly what I am doing (i hope not to forget anything):

1) login normally into gnome

2) enable the 2 upper checkboxes and disable the 2 lower checkboxes in the Remote Desktop Preferences

3) set ubuntu to automatically login into your account in gnome

Steps 1,2 and 3 are to have a setup that is the same as on my machine. Now we come to the steps to reproduce the bug:

4) go to your home folder, open the .dmrc file and replace the word gnome with xfce in the file (xubuntu-desktop is also installed on my machine; I don't know if it matters)

5) restart your ubuntu machine (due to the change in the .dmrc file, it should not anymore automatically login into gnome)

6) login from windows with nx into gnome (i do it from macOSX) using the same user as under 3); that is how I do it; I have not tried with a different user

7) try to login with vnc; here is where the problem occurs

Remarks: Sometimes I get a connection refused, so I wait a bit (several seconds to several dozens of seconds) and try again, several times if necessary; if it still does not connect, logout with nx and login again with nx; then try again to connect with vnc. (Often it does not require several tries for the problem to appear.)

Mark (upstream author) has fixed this issue. Could you try? For your convenience i've made an ubuntu package, download at http://www.gnome.org/~jwendell/vino_2.18.0-0ubuntu1-wendell1_i386.deb

Tell us if that package fixes this issue.

Thanks,

Jonh: do you have the debdiff or fix somewhere?

Hi, Daniel. The patch is on upstream svn:

http://svn.gnome.org/viewcvs/vino?view=rev&sortby=date&revision=565

I just built this package in order to frafu test if the patch solves that problem.

In a normal workflow, this patch will get in vino 2.18.1

Fixed upstream.

Hello,

Good job: the problem seems to be fixed, at least here on my computer.

In fact, I downloaded the debian package provided by Jonh here above, installed it and did a killall -9 vino-server to make sure that the new version is running. (I had to remove vino-dbgsym in order not to have dependencies problems during the installation.)

Now, I am able to connect with vnc to a gnome session that has been opened through nx; the picture in the vnc client is clear and I am also able to control the nxgnome session from within the vnc client window. (Of course, the nx-gnome session is the only gnome session running; as in the circumstances where the bug appeared before the fix.)

Well done. :-)

This upload fixes the bug:

 vino (2.18.1-0ubuntu1) feisty; urgency=low
 .
   * New upstream version:
     Fixes:
     - Fix the non-XDAMAGE, non-XSHM support (Ubuntu: #91973)
     - Fix crash on vino_input_init() (Ubuntu: #92514)
     - Fix crashes on critical warning in vino-preferences applet