longjmp can happen in different places, even after the palette
is allocated so we need to free it if it got allocated.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Uri Lublin <uril@redhat.com>
Instead of using spice_malloc+memcpy use spice_memdup which is
doing the same.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Uri Lublin <uril@redhat.com>
Palette images have padding at the end of each line, so their stride
can't be inferred from their width as is currently done. This causes a
wrong calculation of stride_encoded value which causes a wrong stride
adjustment.
Before commit 5603961ff "fix 16 bpp LZ image decompression", the output
stride was always computed as "stride = (n_comp_pixels / height) * 4"
that is assuming 4 bytes for pixel which was wrong for some output
however computing starting from width was wrong for palette images.
This commit was added to spice-gtk in v0.32~58, which nicely matches the
"client regression when upgrading from spice-gtk v0.31 to spice-gtk
v0.33".
This fix bug https://bugzilla.redhat.com/show_bug.cgi?id=1508847.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Tested-by: Philip J. Turmel <philip@turmel.org>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This flag will allow the client to perform some optimisations
on output and buffering processing.
Old clients will ignore this additional flag.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Most of the documentation is extracted from notes in spice-server
code and comments.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
There's no need for the canvas operations to be changed.
This allows without casts to have the operation structures
constants in the code.
This potentially allows to reduce attack surface having some
more data constant instead or read/write.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe de Dinechin <dinechin@redhat.com>
Just a style change, the variable does not help readability.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe de Dinechin <dinechin@redhat.com>
Is just used by ring_remove, no reason to have it.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe de Dinechin <dinechin@redhat.com>
Allows to test for bad performance on some systems.
For instance on ARMv6/ARMv7 which does not support by default
64 bit unaligned read/write this can be checked on Linux
using /proc/cpu/alignment file.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Instead of assuming that the system can safely do unaligned access
to memory use packed structures to allow the compiler generate
best code possible.
A packed structure tells the compiler to not leave padding inside it
and that the structure can be unaligned so any field can be unaligned
having to generate proper access code based on architecture.
For instance ARM7 can use unaligned access but not for 64 bit
numbers (currently these accesses are emulated by Linux kernel
with obvious performance consequences).
This changes the current methods from:
#ifdef WORDS_BIGENDIAN
#define read_uint32(ptr) ((uint32_t)SPICE_BYTESWAP32(*((uint32_t *)(ptr))))
#define write_uint32(ptr, val) *(uint32_t *)(ptr) = SPICE_BYTESWAP32((uint32_t)val)
#else
#define read_uint32(ptr) (*((uint32_t *)(ptr)))
#define write_uint32(ptr, val) (*((uint32_t *)(ptr))) = val
#endif
to:
#include <spice/start-packed.h>
typedef struct SPICE_ATTR_PACKED {
uint32_t v;
} uint32_unaligned_t;
#include <spice/end-packed.h>
#ifdef WORDS_BIGENDIAN
#define read_uint32(ptr) ((uint32_t)SPICE_BYTESWAP32(((uint32_unaligned_t *)(ptr))->v))
#define write_uint32(ptr, val) ((uint32_unaligned_t *)(ptr))->v = SPICE_BYTESWAP32((uint32_t)val)
#else
#define read_uint32(ptr) (((uint32_unaligned_t *)(ptr))->v)
#define write_uint32(ptr, val) (((uint32_unaligned_t *)(ptr))->v) = val
#endif
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
encodes_ones is called to encode a long sequence of 1 bits.
In some conditions (I manage to reproduce with a 85000x4 pixel
image fill with a single color) encodes_ones is called with a
"n" value >= 32.
This cause encode to be called with a "len" value of 32 which
trigger this assert:
spice_assert(len > 0 && len < 32);
causing a crash. Instead of calling encode with a constant
"len" as 32 call encode_32 which is supposed to encode
exactly 32 bit.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
In most occurrences bppmask is converted to 32 bit anyway.
In the left one a possible more bigger precision is not needed.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
This field is easily accessible from Encoder structure.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
We never change its value, so we basically have 2 constants for the
same thing, DEFwmimax and wmimax. This commit removes the latter.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
We never change its value, so we basically have 2 constants for the
same thing, DEFwminext and wminext. This commit removes the latter
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
We never change 'evol' value, and this is currently causing issues with
gcc 7.1.1: quic.c is checking at compile-time that 'evol' is 1, 3 or 5.
This is a constant, so a static check should be good, but the compiler (gcc
7.1.1) is unable to know 'evol' value at compile-time. Since the removal
of spice_static_assert in favour of SPICE_VERIFY, this causes a
compile-time failure.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
pixman_image_unref() does not ignore NULL pointers, it tries to
dereference it which causes a crash. When trying to decode invalid QUIC
data, we could end up in a situation where 'surface' would still be
NULL when reaching the setjmp block.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
"log: Forbid the usage of obsolete SPICE_LOG_DOMAIN" introduced a small
regression, if G_LOG_DOMAIN is not set when glib.h is included, the
header will set it to a default value. Redefining it later in log.c is
going to cause a compile-time warning.
This commit adds the definition to SPICE_COMMON_CFLAGS so that it's
defined before any inclusion of glib.h is possible. This is similar to
what is done in spice/configure.ac.
This avoids this warning:
CC log.lo
log.c:44:0: warning: "G_LOG_DOMAIN" redefined
#define G_LOG_DOMAIN "Spice"
In file included from /usr/include/glib-2.0/glib.h:62:0,
from log.c:22:
/usr/include/glib-2.0/glib/gmessages.h:280:0: note: this is the location of the previous definition
#define G_LOG_DOMAIN ((gchar*) 0)
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Make sure format is a string and not a pointer.
This prevents usages like:
spice_debug(NULL);
This forbids computed format strings, but on the other hand, forcing
the use of string constants allows the compiler to always check
argument types against the format string. Moreover, there is no
occurrences of computed format strings in the current codebase.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
As we decided to not use multiple GLib domains, the SPICE_LOG_DOMAIN
macro is not really useful. This commit removes it.
Will be replaced by some different categorization.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
The macro was misused and not doing static check.
Spice have other working static check macros to use.
The macro is used only by spice-common so removing it
does not cause issues to other depending projects.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com>
memmove already deal with any alignment so there's no
reason to have row byte pointer cast to uint32_t.
This also remove the confusing "dest" terminology used. The image
is aligned in place so the image bits are used for both destination
and source.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
For example, something like this:
uint8_t *p8;
uint32_t *p32 = (uint32_t *) p8;
generates a warning like this:
spice-channel.c:1350:10: error: cast from 'uint8_t *' (aka 'unsigned char *') to
'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to
4 [-Werror,-Wcast-align]
The warning indicates that we end up with a pointer to data that
should be 4-byte aligned, but its value may be misaligned. On x86,
this does not make much of a difference, except a relatively minor
performance penalty. However, on platforms such as older ARM, misaligned
accesses are emulated by the kernel, and support for them is optional.
So we may end up with a fault.
The intent of the fix here is to make it easy to identify and rework
places where actual mis-alignment occurs. Wherever casts raise the warning,
they are replaced with a macro:
- SPICE_ALIGNED_CAST(type, value) casts value to type, and indicates that
we believe the resulting pointer is aligned. If it is not, a runtime
warning will be issued. This check is disabled unless
--enable-alignment-checks is passed at configure time
- SPICE_UNALIGNED_CAST(type, value) casts value to type, and indicates that
we believe the resulting pointer is not always aligned.
Any code using SPICE_UNALIGNED_CAST may need to be revisited in order
to improve performance, e.g. by using memcpy.
There are normally no warnings for SPICE_UNALIGNED_CAST, but it is possible
to emit debug messages for mis-alignment in SPICE_UNALIGNED_CAST
by configuring with CFLAGS=-DSPICE_DEBUG_ALIGNMENT.
Signed-off-by: Christophe de Dinechin <dinechin@redhat.com>
According to https://developer.gnome.org/glib/stable/glib-running.html,
G_MESSAGES_DEBUG is a space-separated list of log domains for which
informational and debug messages should be printed
Note that the equivalent code in spice-util.c gets it right.
Signed-off-by: Christophe de Dinechin <dinechin@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
As we moved toward GLib logging instead of having to convert
every time the log level from the old system to GLib use
directly GLib constants.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This was suggested by Christophe de Dinechin as an optimisation.
Most of the messages won't be processed for formatting.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Use INT_MAX for invalid value to remove a test in code.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
spice_log_level_to_glib never returns 0 so don't check
for this value.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
License reported for MIT was indeed a BSD 3-Clause license,
not a MIT one (https://opensource.org/licenses/BSD-3-Clause).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Uri Lublin <uril@redhat.com>
Some headers for spice are distributed using MIT licenses.
Allows to generate such headers if needed.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
