Re: [Qemu-devel] [Spice-devel] [PATCH] spice: fix simple display on bigendian hosts

[Gerd Hoffmann <kraxel@redhat.com>]

On Mi, 2015-04-15 at 15:55 +0300, Denis Kirjanov wrote:
> On 4/15/15, Gerd Hoffmann <kraxel@redhat.com> wrote:
> > On Di, 2015-04-14 at 17:47 +0300, Denis Kirjanov wrote:
> >> On 4/14/15, Denis Kirjanov <kirjanov@gmail.com> wrote:
> >> > On 4/14/15, Denis Kirjanov <kirjanov@gmail.com> wrote:
> >> >> On 4/14/15, Gerd Hoffmann <kraxel@redhat.com> wrote:
> >> >>> Denis Kirjanov is busy getting spice run on ppc64 and trapped into
> >> >>> this
> >> >>> one.  Spice wire format is little endian, so we have to explicitly
> >> >>> say
> >> >>> we want little endian when letting pixman convert the data for us.
> >> >>>
> >> >>> Reported-by: Denis Kirjanov <kirjanov@gmail.com>
> >> >>> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> >> >>> ---
> >> >> Yeah, that fixes the issue. Thanks Gerd!
> >> >
> >> > Looks like that the patch fixes the half of the problem: the inverted
> >> > colors appear on client reconnect to vm
> >>
> >> Program received signal SIGSEGV, Segmentation fault.
> >> 0x00007ffff4e10258 in ?? () from
> >> /usr/lib/x86_64-linux-gnu/libpixman-1.so.0
> >> (gdb) bt
> >> #0  0x00007ffff4e10258 in ?? () from
> >> /usr/lib/x86_64-linux-gnu/libpixman-1.so.0
> >> #1  0x00007ffff4e10239 in pixman_image_unref () from
> >> /usr/lib/x86_64-linux-gnu/libpixman-1.so.0
> >> #2  0x00007ffff78e4117 in canvas_get_quic
> >> (canvas=canvas@entry=0x7ceb80, image=image@entry=0xae2720,
> >>     want_original=want_original@entry=0) at
> >> ../spice-common/common/canvas_base.c:390
> >
> > spice client crash?
> > is this spice client running on big endian or little endian machine?
> 
> it's running on x86_64 as shown in the stack trace.

Hmm.  spice client should not crash no matter what.

But beside that it is entirely possible that there is a byteswap missing
somewhere in either qemu or spice-server where bigendian is sent instead
of little endian, which in turn triggers the bug in the client.

IIRC spice protocol support was added to wireshark a while back, so it
should be possible to run tests and compare traces to le + be hosts to
see whenever there is something wrong in the wire format.  Which should
help tracing down the bug in the source code.

HTH,
  Gerd