[Spice-devel] spice-gtk hangs

[Hans de Goede]

Hi,

On 09/16/2011 12:29 PM, Damien Churchill wrote:
> On 8 September 2011 15:22, Marc-André Lureau<mlureau at 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