Re: [Pixman] debuging wxruby
Svend Haugaard Sørensen s...@demosophia.net writes: On Sun, 07 Oct 2012 05:10:18 +0200 sandm...@cs.au.dk (Søren Sandmann) wrote: Svend Haugaard Sørensen s...@demosophia.net writes: The top of the stack dump look like this. #0 0xb47a6d9d in _pixman_lookup_composite_function (toplevel=0x80be750, op=PIXMAN_OP_SRC, src_format2144, src_flags43063, mask_format=0, mask_flags92, dest_format=PIXMAN_a8r8g8b8, dest_flags4032255, out_imp=0xbfffb82c, out_func=0xbfffb828) at /var/tmp/portage/x11-libs/pixman-0.26.0/work/pixman-0.26.0/pixman/pixman-utils.c:74 A crash at this point suggests that something is broken with thread local storage on your setup. When you compiled pixman, which type of thread local storage was detected by the configure script? Søren The configure script write this to the output. checking for thread local storage (TLS) support... __thread I have posted the complete output on the gentoo forum. http://forums.gentoo.org/viewtopic-p-7157526.html#7157526 Most likely the issue is the same as in this bug: https://bugs.freedesktop.org/show_bug.cgi?id=34335 where some other library is using the TLS model initial-exec, which then conflicts with pixman using the dynamic model. Søren ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] debuging wxruby
On Sun, 07 Oct 2012 20:51:28 +0200 sandm...@cs.au.dk (Søren Sandmann) wrote: Svend Haugaard Sørensen s...@demosophia.net writes: On Sun, 07 Oct 2012 05:10:18 +0200 sandm...@cs.au.dk (Søren Sandmann) wrote: Svend Haugaard Sørensen s...@demosophia.net writes: The top of the stack dump look like this. #0 0xb47a6d9d in _pixman_lookup_composite_function (toplevel=0x80be750, op=PIXMAN_OP_SRC, src_format2144, src_flags43063, mask_format=0, mask_flags92, dest_format=PIXMAN_a8r8g8b8, dest_flags4032255, out_imp=0xbfffb82c, out_func=0xbfffb828) at /var/tmp/portage/x11-libs/pixman-0.26.0/work/pixman-0.26.0/pixman/pixman-utils.c:74 A crash at this point suggests that something is broken with thread local storage on your setup. When you compiled pixman, which type of thread local storage was detected by the configure script? Søren The configure script write this to the output. checking for thread local storage (TLS) support... __thread I have posted the complete output on the gentoo forum. http://forums.gentoo.org/viewtopic-p-7157526.html#7157526 Most likely the issue is the same as in this bug: https://bugs.freedesktop.org/show_bug.cgi?id=34335 where some other library is using the TLS model initial-exec, which then conflicts with pixman using the dynamic model. And how do we find, test and fix that?? Is the TLS supported by a certain dynamic library? Because the I can search for it. PS. I don't use mesa, but the nvidia driver. ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] debuging wxruby
Svend Haugaard Sørensen s...@demosophia.net writes: Most likely the issue is the same as in this bug: https://bugs.freedesktop.org/show_bug.cgi?id4335 where some other library is using the TLS model initial-exec, which then conflicts with pixman using the dynamic model. And how do we find, test and fix that?? Is the TLS supported by a certain dynamic library? Because the I can search for it. PS. I don't use mesa, but the nvidia driver. It's possible that the root cause is this bug in glibc: http://sourceware.org/bugzilla/show_bug.cgi?id=12453 If your C library is older than that, I'd try updating it first. Søren ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] debuging wxruby
On Mon, 08 Oct 2012 00:23:21 +0200 sandm...@cs.au.dk (Søren Sandmann) wrote: Is the TLS supported by a certain dynamic library? Because the I can search for it. PS. I don't use mesa, but the nvidia driver. It's possible that the root cause is this bug in glibc: http://sourceware.org/bugzilla/show_bug.cgi?id=12453 If your C library is older than that, I'd try updating it first. They are, so I will try, but it might take some time. Søren ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
[Pixman] [PATCH] Only regard images as pixbufs if they have identity transformations
From: Søren Sandmann Pedersen s...@redhat.com
In order for a src/mask pair to be considered a pixbuf, they have to
have identical transformations, but we don't check for that. Since the
only fast paths we have for pixbufs require identity transformations,
it sufficies to check that both source and mask are
untransformed.
This is also the reason that this bug can't be triggered by any test
code - if the source and mask had different transformations, we would
consider them a pixbuf, but then wouldn't take the fast path because
at least one of the transformations would be different from the
identity.
---
pixman/pixman.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/pixman/pixman.c b/pixman/pixman.c
index bbe8b08..e3b6516 100644
--- a/pixman/pixman.c
+++ b/pixman/pixman.c
@@ -605,6 +605,7 @@ pixman_image_composite32 (pixman_op_t op,
if ((mask_format == PIXMAN_a8r8g8b8 || mask_format == PIXMAN_a8b8g8r8)
(src-type == BITS src-bits.bits == mask-bits.bits)
(src-common.repeat == mask-common.repeat)
+ (src_flags mask_flags FAST_PATH_ID_TRANSFORM)
(src_x == mask_x src_y == mask_y))
{
if (src_format == PIXMAN_x8b8g8r8)
--
1.7.11.4
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
