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 423887 - vino crashed in a NX environment
vino crashed in a NX environment
Status: RESOLVED FIXED
Product: vino
Classification: Applications
Component: Server
2.18.x
Other Linux
: Normal major
: ---
Assigned To: Vino Maintainer(s)
Vino Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2007-03-28 20:37 UTC by Jonh Wendell
Modified: 2007-03-29 10:41 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
vino-fix-non-xdamage-non-xshm-support.patch (1.33 KB, patch)
2007-03-29 10:41 UTC, Mark McLoughlin
none Details | Review

Description Jonh Wendell 2007-03-28 20:37:36 UTC
From ubuntu (http://launchpad.net/bugs/91973):

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.)
Comment 1 Mark McLoughlin 2007-03-29 09:25:21 UTC
Note, the crash is happening in g_type_check_class_cast() which perhaps suggests memory corruption of some sort - e.g. the VinoStatusIcon has already been freed or  some other code has trampled over its memory.

That's why I suggested valgrind --tool=memcheck - it might catch one of these two cases. So, all the information about leaks in the logs isn't useful; running without --leak-check=yes would be just as useful.

It looks like the problem is somewhere in the non-XSHM, non-XDAMAGE code which isn't often used these days. That would make sense - NX probably doesn't support these extensions.

So, you could probably try and debug this code by manually disabling XSHM and XDAMAGE by replacing XDamageQueryExtension() and XShmQueryExtension() with False.

Two things suggest this to me:

  1) The screenshot of the display shows a strange type of corruption which
     looks like the 32x32 pixel tiles are messed up somehow. We only read
     the screen contents in tiles like this when XDAMAGE isn't available.

  2) This trace shows us executing the non-XSHM code, and suggests that
     when we're reading a scanline, we read a pixel more than we had allocated
     memory for:

==5255== Invalid write of size 4
==5255==    at 0x468FEB4: (within /usr/lib/libX11.so.6.2.0)
==5255==    by 0x4690187: _XSetImage (in /usr/lib/libX11.so.6.2.0)
==5255==    by 0x468CA68: XGetSubImage (in /usr/lib/libX11.so.6.2.0)
==5255==    by 0x805385D: vino_fb_get_image (vino-fb.c:173)
==5255==    by 0x80539EF: vino_fb_poll_screen (vino-fb.c:374)
==5255==    by 0x46043C5: (within /usr/lib/libglib-2.0.so.0.1200.11)
==5255==    by 0x4603DF1: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.1200.11)
==5255==    by 0x4606DCE: (within /usr/lib/libglib-2.0.so.0.1200.11)
==5255==    by 0x4607178: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.1200.11)
==5255==    by 0x4291043: gtk_main (in /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==5255==    by 0x80548F9: main (vino-main.c:98)
==5255==  Address 0x526A920 is 0 bytes after a block of size 2,952 alloc'd
==5255==    at 0x4021620: malloc (vg_replace_malloc.c:149)
==5255==    by 0x8052FBB: vino_fb_create_image (vino-fb.c:293)
==5255==    by 0x80531CE: vino_fb_init_from_screen (vino-fb.c:750)
==5255==    by 0x458F9DB: (within /usr/lib/libgobject-2.0.so.0.1200.11)
==5255==    by 0x458DA7A: g_object_newv (in /usr/lib/libgobject-2.0.so.0.1200.11)
==5255==    by 0x458E698: g_object_new_valist (in /usr/lib/libgobject-2.0.so.0.1200.11)
==5255==    by 0x458E79F: g_object_new (in /usr/lib/libgobject-2.0.so.0.1200.11)
==5255==    by 0x80527CD: vino_fb_new (vino-fb.c:1048)
==5255==    by 0x805863E: vino_server_handle_new_client (vino-server.c:693)
==5255==    by 0x80615BA: rfbNewClient (rfbserver.c:273)
==5255==    by 0x80632AA: rfbProcessNewConnection (sockets.c:268)
==5255==    by 0x8057D29: vino_server_new_connection_pending (vino-server.c:396)
Comment 2 Mark McLoughlin 2007-03-29 10:41:06 UTC
Created attachment 85508 [details] [review]
vino-fix-non-xdamage-non-xshm-support.patch
Comment 3 Mark McLoughlin 2007-03-29 10:41:32 UTC
Okay, got it:

2007-03-29  Mark McLoughlin  <mark@skynet.ie>

        Fix the non-XDAMAGE, non-XSHM support (bug #423887)

        * server/vino-fb.c: (vino_fb_create_image): create the
        XImage data only after allocating the XImage itself
        where the actual rowstride is calculated, rather than
        making a lame attempt at guessing what rowstride will
        be used.