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] debuging wxruby
I can't run my wxruby application because wxruby crash on every application. I have made a stack dump and the libraries involved in the crash is ruby-1.8.7_p352 glib-2.30.3 cairo-1.10.2-r2 gtk+-2.24.5-r1 pixman-0.26.0 wxGTK-2.8.12.1 gtk-engines-2.20.2 As far as I can read on the web pixman is strongly involved but, is it an error in pixman or in libraries calling pixman? I have started to document the problem in this forum thread. http://forums.gentoo.org/viewtopic-t-938578.html I hope we can use our collective intelligence to solve this problem. It seams to be a cross library problem, so we will have to work together on this one. The top of the stack dump look like this. #0 0xb47a6d9d in _pixman_lookup_composite_function (toplevel=0x80be750, op=PIXMAN_OP_SRC, src_format=262144, src_flags=1043063, mask_format=0, mask_flags=8192, dest_format=PIXMAN_a8r8g8b8, dest_flags=34032255, 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 #1 0xb4618b32 in pixman_image_composite32 (op=PIXMAN_OP_SRC, src=0x837cac0, mask=0x0, dest=0x837cba8, src_x=0, src_y=0, mask_x=0, mask_y=0, dest_x=0, dest_y=0, width=8, height=35) at /var/tmp/portage/x11-libs/pixman-0.26.0/work/pixman-0.26.0/pixman/pixman.c:682 #2 0xb62a7889 in _cairo_pattern_acquire_surface_for_gradient (pattern=0xbfffc84c, dst=0x837c508, x=0, y=0, width=8, height=35, out=0xbfffbc74, attr=0xbfffbcc0) at cairo-pattern.c:1524 #3 0xb62a9a31 in _cairo_pattern_acquire_surface (pattern=0xbfffc84c, dst=0x837c508, x=0, y=0, width=400, height=35, flags=0, surface_out=0xbfffbc74, attributes=0xbfffbcc0) at cairo-pattern.c:2534 #4 0xb62a9c15 in _cairo_pattern_acquire_surfaces (src=0xbfffc84c, mask=0x0, dst=0x837c508, src_x=0, src_y=0, mask_x=0, mask_y=0, width=400, height=35, flags=0, src_out=0xbfffbc74, mask_out=0xbfffbc70, src_attributes=0xbfffbcc0, mask_attributes=0xbfffbc78) at cairo-pattern.c:2613 #5 0xb62e1d38 in _cairo_xlib_surface_acquire_pattern_surfaces (display=0x837c3e8, dst=0x837c508, src=0xbfffc84c, mask=0x0, src_x=0, src_y=0, mask_x=0, mask_y=0, width=400, height=35, src_out=0xbfffbc74, mask_out=0xbfffbc70, src_attr=0xbfffbcc0, mask_attr=0xbfffbc78) at cairo-xlib-surface.c:2299 #6 0xb62e21e2 in _cairo_xlib_surface_composite (op=CAIRO_OPERATOR_OVER, src_pattern=0xbfffc84c, mask_pattern=0x0, abstract_dst=0x837c508, src_x=0, src_y=0, mask_x=0, mask_y=0, dst_x=0, dst_y=0, width=400, height=35, clip_region=0x0) at cairo-xlib-surface.c:2466 #7 0xb62ba341 in _cairo_surface_composite (op=CAIRO_OPERATOR_OVER, src=0xbfffc84c, mask=0x0, dst=0x837c508, src_x=0, src_y=0, mask_x=0, mask_y=0, dst_x=0, dst_y=0, width=400, height=35, clip_region=0x0) at cairo-surface.c:1802 #8 0xb62bd7ce in _composite_rectangle (dst=0x837c508, op=CAIRO_OPERATOR_OVER, src=0xbfffc84c, traps=0xbfffc11c, clip=0x0) at cairo-surface-fallback.c:762 ___ 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: The top of the stack dump look like this. #0 0xb47a6d9d in _pixman_lookup_composite_function (toplevel=0x80be750, op=PIXMAN_OP_SRC, src_format=262144, src_flags=1043063, mask_format=0, mask_flags=8192, dest_format=PIXMAN_a8r8g8b8, dest_flags=34032255, 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 ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
