Hi,
On 09/16/2011 12:29 PM, Damien Churchill wrote:
On 8 September 2011 15:22, Marc-André Lureau<mlur...@redhat.com> wrote:
Hi
----- Original Message -----
Hi there,
I've created a simple viewer application in Python, using the
spice-gtk library. It seems to be suffering from an issue where it
will occasionally just hang the display, and the only way to get it
back is to close the application and re-connect. Is this something
anyone else has experienced at all? It seems to happen after some time
(hours) of use.
Nobody reported this problem before, afaik.
Can you reproduce it with a different client, like spicy or virt-manager.
spicy doesn't seem to play nicely with the clipboard, at least on the
machines I've tried, so I haven't been able to test that out. Haven't
tried out virt-manager yet as it doesn't support multiple displays, as
fair as I know anyway.
Are you building spice-gtk from source?
I'm building Ubuntu packages from source (0.7) since there aren't any
official ones that I can see, or at least up to date copies.
Feel free to file a detailed bug report in bugzilla.freedesktop.org
I set spice_util_set_debug to True in my program and here is an
extract of the output leading up to when it hangs:
(vviewer:19988): GSpice-DEBUG: spice-channel-cache.h:91 cache_find:
image 59eab89e246f0529 [not found]
(vviewer:19988): GSpice-DEBUG: spice-channel-cache.h:107 cache_add:
image 59eab89e246f0529 (175)
(vviewer:19988): GSpice-DEBUG: channel-cursor.c:331 set_cursor: type
0, 1c, 41x39, flags 4, size 0
(vviewer:19988): GSpice-DEBUG: decode-glz.c:368 decode_header:
980x123, id 50343, ref 50257
(vviewer:19988): GSpice-DEBUG: decode-glz.c:368 decode_header:
980x123, id 50344, ref 50257
(vviewer:19988): GSpice-DEBUG: decode-glz.c:368 decode_header:
980x123, id 50345, ref 50257
(vviewer:19988): GSpice-DEBUG: decode-glz.c:368 decode_header:
980x123, id 50346, ref 50257
(vviewer:19988): GSpice-DEBUG: decode-glz.c:368 decode_header:
980x123, id 50347, ref 50257
(vviewer:19988): GSpice-DEBUG: channel-display.c:872
display_handle_stream_create: id 49
(vviewer:19988): GSpice-DEBUG: channel-display.c:925 scheduling next
stream render in 391 ms
(vviewer:19988): GSpice-DEBUG: channel-cursor.c:331 set_cursor: type
0, 1f, 41x39, flags 4, size 0
(vviewer:19988): GSpice-DEBUG: channel-cursor.c:331 set_cursor: type
0, 1f, 41x39, flags 4, size 0
(vviewer:19988): GSpice-DEBUG: decode-glz.c:368 decode_header:
980x197, id 50348, ref 50257
(vviewer:19988): GSpice-DEBUG: decode-glz.c:368 decode_header: 24x38,
id 50349, ref 50257
(vviewer:19988): GSpice-DEBUG: decode-glz.c:368 decode_header: 440x22,
id 50350, ref 50257
(vviewer:19988): GSpice-DEBUG: decode-glz.c:368 decode_header: 440x22,
id 50351, ref 50257
(vviewer:19988): GSpice-DEBUG: decode-glz.c:368 decode_header: 440x22,
id 50352, ref 50257
(vviewer:19988): GSpice-CRITICAL **: stream_mjpeg_data: assertion `j
== st->mjpeg_cinfo.rec_outbuf_height' failed
(vviewer:19988): GSpice-DEBUG: channel-display.c:925 scheduling next
stream render in 32 ms
(vviewer:19988): GSpice-DEBUG: channel-cursor.c:331 set_cursor: type
0, 1c, 41x39, flags 4, size 0
(vviewer:19988): GSpice-DEBUG: channel-cursor.c:331 set_cursor: type
0, 1c, 41x39, flags 4, size 0
Improper call to JPEG library in state 205
I note that there are some mjpeg fixes shortly after the 0.7 release
in the git commit log, would it be worth back-porting those to see how
that works?
Judging from the above, you're hitting the bug those jpeg fixes fix,
so yes it definitely is a good idea to do a build with those fixes
included.
Regards,
Hans
_______________________________________________
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
