Hi. What version of gtk-vnc are you using?

Could you compile gtk-vnc with the flag --enable-debug in configure script and run vinagre in a terminal? Paste here the output, please.

I've rebuilt gtk-vnc (0.3.3) with --enable-debug=yes and there's _zero_ output stdout/stderr when it crashes... :/

Is there anything else I could do?

Hum, I update our gtk-vnc to 0.3.4 and got the following output

$ vinagre 
Expose 0x0 @ 1,1
Started background coroutine
Resolving host macros.local 5900
Doing final VNC cleanup
Requesting that VNC close
Cannot access memory at address 0xb1236004
Cannot access memory at address 0xb1236004

Hmmm, very weird... What's your VNC server? Have you tried with the IP address instead of the name?

The vnc server is a vino on an Ubuntu (7.10) x86 box. I have also tried reaching that box using its IP rather than through its dns-sd name provided by avahi. No change at all.

Same crash if I connect to a vino server running on my own laptop.

Hi. Could you paste here again the backtrace along with the terminal output for the same crash?

I'd like to see the address listed in 'Cannot access memory at address XXX' in the backtrace.

By the way, do you have the chance to connect to another server rather than vino?

Thanks.

Created attachment 107341 [details]
vinagre-bug-buddy-report.txt (with gtk-vnc-0.3.4)

atmos.local is my own machine (vino-2.22.0). Vino is set up to to ask me to confirm each incoming connection, and FWIW it actually never asks anything before vinagre crashes. As for other VNC servers, I don't have any others available.

command line output :

$ vinagre 
Expose 0x0 @ 1,1
Started background coroutine
Resolving host atmos.local 5900
Doing final VNC cleanup
Requesting that VNC close
Cannot access memory at address 0xb1226004
Cannot access memory at address 0xb1226004

Hi.

Please, try the development version of gtk-vnc, as explained at http://gtk-vnc.sourceforge.net/Code

Build it with --enable-debug and run vinagre in a terminal. Past here the output.

Thanks.

$ hg log -r tip
changeset:   187:a0c03e9f8ec1
tag:         tip
user:        Jonh Wendell <wendell@bani.com.br>
date:        Sat Mar 15 17:55:32 2008 -0300
summary:     Put more debug output

$ grep "$ ./configure" config.log 
  $ ./configure --enable-warnings --prefix=/home/remi/Projets/root/ --enable-debug

$ LD_LIBRARY_PATH=/home/remi/Projets/root/lib/ ldd /usr/bin/vinagre | grep vnc
	libgtk-vnc-1.0.so.0 => /home/remi/Projets/root/lib/libgtk-vnc-1.0.so.0 (0xb7e2f000)

== connection using dns-sd (using the "Find" button in the connection dialog) ==

$ LD_LIBRARY_PATH=/home/remi/Projets/root/lib/ /usr/bin/vinagre
Expose 0x0 @ 1,1
Started background coroutine
Resolving host macros.local 5900
Failed to resolve hostname
Doing final VNC cleanup
Requesting that VNC close

[vinagre tries to display a popup/alert window, bug-buddy pops up]

== connection using IP address ==

$ LD_LIBRARY_PATH=/home/remi/Projets/root/lib/ /usr/bin/vinagre
Expose 0x0 @ 1,1
Started background coroutine
Resolving host 192.168.0.14 5900
Trying socket 14
Protocol initialization
Negotiated protocol 3 7
Possible auth 18
Possible auth 1
Requested auth type 18
Waiting for auth type
Choose auth 18
Do TLS handshake
Handshake was blocking
Handshake was blocking
Handshake was blocking
Handshake was blocking
Handshake done
Completed TLS setup
Possible sub-auth 1
Requested auth subtype 1
Waiting for auth subtype
Choose auth 1
Pixel format BPP: 32,  Depth: 24, Byte order: 1234, True color: 1
             Mask  red: 255, green: 255, blue: 255
             Shift red:  16, green:   8, blue:   0
Display name 'partage@macros'
Mask local: 255 255 255
    remote: 255 255 255
    merged: 255 255 255
Pixel shifts
   right:  16   8   0
    left:  16   8   0
Expose 0x0 @ 717,489
Running main loop
FramebufferUpdate(7, 0, 0, 1360, 48)
Closing the connection: gvnc_read() - gvnc_zread() failed
FramebufferUpdate(0, 0, 0, 0, 0)
FramebufferUpdate(0, 0, 0, 0, 0)
FramebufferUpdate(0, 0, 0, 0, 0)
FramebufferUpdate(0, 0, 0, 0, 0)
FramebufferUpdate(0, 0, 0, 0, 0)
FramebufferUpdate(0, 0, 0, 0, 0)
FramebufferUpdate(0, 0, 0, 0, 0)
FramebufferUpdate(0, 0, 0, 0, 0)
FramebufferUpdate(0, 0, 0, 0, 0)
FramebufferUpdate(0, 0, 0, 0, 0)
FramebufferUpdate(0, 0, 0, 0, 0)
FramebufferUpdate(0, 0, 0, 0, 0)
FramebufferUpdate(0, 0, 0, 0, 0)
FramebufferUpdate(0, 0, 0, 0, 0)
FramebufferUpdate(0, 0, 0, 0, 0)
Doing final VNC cleanup
Requesting that VNC close

[same crash as before but I see vinagre actually resizing the framebuffer display area as the scrollbars appear around the widget, then crash+bug-buddy]

The traces from your last complete show 2 completely separate bugs

 - Crash during cleanup from dealing with an invalid hostname
 - Incompatability when dealing with ZRLE framebuffer update encoding

The first problem is probably a ref-counting / cleanup bug.

The second problem is already being investigated - it is believed that the VNC server is violating the RFB specification when sending ZRLE updates. The question we're attempting to answer is whether all VNC servers violate it in the same way - if so, then GTK-VNC can workaround this problem easily.

Rémi, could you test the same thing, but using gvncviewer instead of vinagre? It's located inside examples/ dir in gtk-vnc folder.

./gvncviewer 192.168.0.14 works. No crash on start-up, nor after a few minutes of usage. (that's with the same hg changeset previously mentioned)

Ok, but could you paste here the output of the gvncviewer usage?

Created attachment 107964 [details]
gvncviewer.log

Here's the command line I used : LD_LIBRARY_PATH=/home/remi/Projets/root/lib/ ./gvncviewer 192.168.0.14

I don't know if that's enough for python to pick things up from my prefix or not.

@Dan, please see the latest lines from the log above:

Requesting that VNC close
Requesting graceful shutdown of connection
Waking up couroutine to shutdown gracefully
Connected to server
Remote desktop size changed to 1360x768
Connection initialized

Notice two things:
1) There's no finalization (Where's the message "Releasing VNC widget" ?), which makes me think that the widget is not being handled correctly by gvncviewer.

2) What are those messages: "Connected to server... etc" just after disconnection?

Rémi, why are you using LD_LIBRARY_PATH=/home/remi/Projets/root/lib/ ?

Does it work without setting this var?

Also, do you have jabber or even an irc nick? I'm jwendell on freenode, gimpnet and oftc. My jabber is jonh.wendell_at_gmail.com

(In reply to comment #17)
> Rémi, why are you using LD_LIBRARY_PATH=/home/remi/Projets/root/lib/ ?

Just to make sure that the right library gets picked up. I'm not at all sure this is required :)

> Does it work without setting this var?

Nope it crashes too. I'm not sure what that's supposed to imply though.

> Also, do you have jabber or even an irc nick? I'm jwendell on freenode, gimpnet
> and oftc. My jabber is jonh.wendell_at_gmail.com

I'm "remi`" (with the backtick) on freenode. Unfortunately, I don't usually hang out on IRC at home. I'll try to ping you tomorrow or next week.

Thanks for looking into this.

Hi, Rémi. Could you try the following patch for gtk-vnc made by Dan?

---------------------------------------
diff -r 2ca361cd74cd src/continuation.c
--- a/src/continuation.c        Wed Apr 02 09:22:31 2008 -0500
+++ b/src/continuation.c        Wed Apr 02 13:55:09 2008 -0400
@@ -10,8 +10,31 @@
 
 #include "continuation.h"
 
+/*
+ * va_args to makecontext() must be type 'int', so passing
+ * the pointer we need may require several int args. This
+ * union is a quick hack to let us do that
+ */
+union cc_arg {
+       void *p;
+       int i[2];
+};
+
+static void continuation_trampoline(int i0, int i1)
+{
+       union cc_arg arg;
+       struct continuation *cc;
+       arg.i[0] = i0;
+       arg.i[1] = i1;
+       cc = arg.p;
+
+       cc->entry(cc);
+}
+
 int cc_init(struct continuation *cc)
 {
+       union cc_arg arg;
+       arg.p = cc;
        if (getcontext(&cc->uc) == -1)
                return -1;
 
@@ -20,7 +43,7 @@
        cc->uc.uc_stack.ss_size = cc->stack_size;
        cc->uc.uc_stack.ss_flags = 0;
 
-       makecontext(&cc->uc, (void *)cc->entry, 1, cc);
+       makecontext(&cc->uc, (void *)continuation_trampoline, 2, arg.i[0], arg.i[1]);
 
        return 0;
 }
------------------------------------------

Brilliant! It works! Both in gvncviewer and vinagre.

So now, vinagre only segfaults when I use the avahi browsing feature instead of typing the IP address manually (I should point out that I don't have nss_mdns enabled, but vinagre shouldn't crash)

It also crashes when I went to the File menu and when I clicked on "Close connection". Should I open another bug for that?

Thanks

(In reply to comment #20)
> Brilliant! It works! Both in gvncviewer and vinagre.

OK, this patch is going to be committed soon.

> So now, vinagre only segfaults when I use the avahi browsing feature instead of
> typing the IP address manually (I should point out that I don't have nss_mdns
> enabled, but vinagre shouldn't crash)

What do you mean by "I don't have nss_mdns enabled"? There's no avahi-daemon running?
Anyway, could you attach a backtrace of this crash?

> It also crashes when I went to the File menu and when I clicked on "Close
> connection". Should I open another bug for that?

Could you attach another backtrace for this crash?


Thanks.

Hey, last crash has been fixed in development version of gtk-vnc.

I'll close this bug for now. If you have some useful information for the crash with avahi, please reopen it.

Thanks.