On 01/13/13 02:35, Juan Francisco Cantero Hurtado wrote:
On 01/12/13 12:40, Søren Sandmann wrote:
Chris Wilson <ch...@chris-wilson.co.uk>
writes:
We can not rely on the value of func after
_pixman_implementation_lookup_composite() as the sole means of
identifying a bogus implementation as it is left uninitialized on the
error path. Instead we need to check the explicit return value.
_pixman_implementation_lookup_composite() is not supposed to fail ever
because eventually it will find general_composite_rectangle() which can
always be used. When it does fail, it is almost always because something
is broken with TLS support so that the fast path cache is messed up.
OpenBSD and gcc 4.2 (the default compiler) don't support thread local
storage.
Juan, can you send config.log from when you compiled pixman, and also
let us know what the line
#define TLS ...
in config.h says?
/* The compiler supported TLS storage class */
/* #undef TLS */
http://juanfra.info/bugs-y-listas/cairo-racket-201301/config.log
http://juanfra.info/bugs-y-listas/cairo-racket-201301/config.h
And here is the original thread in the cairo list:
http://thread.gmane.org/gmane.comp.lib.cairo/23503/focus=23509
Reported-by: Juan Francisco Cantero Hurtado
<i...@juanfra.info>
Signed-off-by: Chris Wilson
<ch...@chris-wilson.co.uk>
---
pixman/pixman-glyph.c | 30 +++++++++++++-----------------
1 file changed, 13 insertions(+), 17 deletions(-)
Regarding the patch, if we want to make this more robust, I think a
better course of action would be to set func to NULL and call
_pixman_log_error() with some suitable message about TLS before
returning FALSE in _pixman_implementation_lookup_composite().
Or alternatively, make it so that
_pixman_implementation_lookup_composite() definitely can't fall by
returning some dummy compositing function.
Soren
_______________________________________________
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
