wxRuby crashes with segmentation fault in pixman_image_composite32

[David Beswick]

Edited: I corrected the repro steps, thanks Marvin

This is a strange one, I'm not sure exactly where the fault lies. Basically, performing almost any operation in a wxRuby app causes a crash in pixman_image_composite32. This crash doesn't occur when running regular wxWidgets apps or wxPython apps. The problem occurs on both ruby 1.8 and 1.9.1. It also occurs across all versions of wxRuby. The bug doesn't show up on all linux distos (success has been reported with Arch linux) but I think that's determined by the version of pixman that the distro is using.

To repro:

1. Install ruby 1.9.1: sudo apt-get install ruby1.9.1
2. Install the wxWidgets gem: sudo gem1.9.1 install wxruby-ruby19
3. Run the wxRuby bigdemo sample: ruby1.9.1 /var/lib/gems/1.9.1/gems/wxruby-ruby19-2.0.0-x86_64-linux/samples/bigdemo/bigdemo.rb
4. A segmentation fault occurs.

I've got wxRuby working by disabling some code in pixman. In the file pixman/pixman.c, function "lookup_composite_function", I
ifdef-ed out the following code:

 for (i = 0; i < N_CACHED_FAST_PATHS; ++i)
 {
    const pixman_fast_path_t *info = &(cache->cache[i].fast_path);

    /* Note that we check for equality here, not whether
     * the cached fast path matches. This is to prevent
     * us from selecting an overly general fast path
     * when a more specific one would work.
     */
    if (info->op == op &&
        info->src_format == src_format &&
        info->mask_format == mask_format &&
        info->dest_format == dest_format &&
        info->src_flags == src_flags &&
        info->mask_flags == mask_flags &&
        info->dest_flags == dest_flags &&
        info->func)
    {
        *out_imp = cache->cache[i].imp;
        *out_func = cache->cache[i].fast_path.func;

        goto update_cache;
    }
}

The bug doesn't occur after this modified version of pixman has been installed. As far as I can see, the cache->cache[i].fast_path.func pointer is pointing to an invalid location. I think the usual target of these pointers is the following variable in pixman.c:

PIXMAN_DEFINE_THREAD_LOCAL (cache_t, fast_path_cache);

This thread local variable seems to be uninitialized or filled with garbage when the crash occurs.

Here's a backtrace from ruby 1.9.1 illustrating the crash:

-- C level backtrace information -------------------------------------------
/usr/lib/libruby-1.9.1.so.1.9(rb_vm_bugreport+0x5f) [0x7fdd5531be8f]
/usr/lib/libruby-1.9.1.so.1.9(+0x58a56) [0x7fdd55226a56]
/usr/lib/libruby-1.9.1.so.1.9(rb_bug+0xb3) [0x7fdd55226bc3]
/usr/lib/libruby-1.9.1.so.1.9(+0xedde5) [0x7fdd552bbde5]
/lib/libpthread.so.0(+0xfb40) [0x7fdd54fc0b40]
/usr/local/lib/libpixman-1.so.0(pixman_image_composite32+0x300) [0x7fdd4a296700]
/usr/lib/libcairo.so.2(+0x29463) [0x7fdd4b3b9463]
/usr/lib/libcairo.so.2(+0x2a61c) [0x7fdd4b3ba61c]
/usr/lib/libcairo.so.2(+0x2c31d) [0x7fdd4b3bc31d]
/usr/lib/libcairo.so.2(+0x2c55e) [0x7fdd4b3bc55e]
/usr/lib/libcairo.so.2(+0x49f56) [0x7fdd4b3d9f56]
/usr/lib/libcairo.so.2(+0x2243e) [0x7fdd4b3b243e]
/usr/lib/libcairo.so.2(cairo_fill_preserve+0x1d) [0x7fdd4b3a943d]
/usr/lib/libcairo.so.2(cairo_fill+0x9) [0x7fdd4b3a9469]
/usr/lib/librsvg-2.so.2(+0x2a1b0) [0x7fdd43bc91b0]
/usr/lib/librsvg-2.so.2(+0x248a0) [0x7fdd43bc38a0]
/usr/lib/librsvg-2.so.2(+0x1eb53) [0x7fdd43bbdb53]
/usr/lib/librsvg-2.so.2(+0x1f093) [0x7fdd43bbe093]
/usr/lib/librsvg-2.so.2(+0x1eb53) [0x7fdd43bbdb53]
/usr/lib/librsvg-2.so.2(+0x1f093) [0x7fdd43bbe093]
/usr/lib/librsvg-2.so.2(+0x1eb53) [0x7fdd43bbdb53]
/usr/lib/librsvg-2.so.2(+0x1ef64) [0x7fdd43bbdf64]
/usr/lib/librsvg-2.so.2(+0x1eb53) [0x7fdd43bbdb53]
/usr/lib/librsvg-2.so.2(rsvg_handle_render_cairo_sub+0xca) [0x7fdd43bc9b1a]
/usr/lib/librsvg-2.so.2(rsvg_handle_get_pixbuf_sub+0x105) [0x7fdd43bca065]
/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so(+0xd6b) [0x7fdd43dfdd6b]
/usr/lib/libgdk_pixbuf-2.0.so.0(gdk_pixbuf_loader_close+0xf9) [0x7fdd4ffce889]
/usr/lib/libgdk_pixbuf-2.0.so.0(+0x89a6) [0x7fdd4ffcc9a6]
/usr/lib/libgdk_pixbuf-2.0.so.0(gdk_pixbuf_new_from_stream_at_scale+0x81) [0x7fdd4ffccb01]
/usr/lib/libgtk-x11-2.0.so.0(+0x104eec) [0x7fdd507b3eec]
/usr/lib/libgtk-x11-2.0.so.0(gtk_icon_info_load_icon+0x72) [0x7fdd507b4612]
/usr/lib/libgtk-x11-2.0.so.0(gtk_icon_theme_load_icon+0x13f) [0x7fdd507b685f]
/usr/lib/libgtk-x11-2.0.so.0(gtk_icon_set_render_icon+0x5ea) [0x7fdd507b0faa]
/usr/lib/libgtk-x11-2.0.so.0(gtk_widget_render_icon+0xea) [0x7fdd5090834a]
/usr/lib/libgtk-x11-2.0.so.0(+0x1185d4) [0x7fdd507c75d4]
/usr/lib/libgtk-x11-2.0.so.0(+0x1185f9) [0x7fdd507c75f9]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0xa9) [0x7fdd4f7299b9]
/usr/lib/libgobject-2.0.so.0(+0x246b1) [0x7fdd4f73f6b1]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x7e6) [0x7fdd4f7412a6]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_by_name+0x208) [0x7fdd4f7415f8]
/usr/lib/libgtk-x11-2.0.so.0(+0x1a5138) [0x7fdd50854138]
/usr/lib/libgtk-x11-2.0.so.0(+0x85967) [0x7fdd50734967]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0xa9) [0x7fdd4f7299b9]
/usr/lib/libgobject-2.0.so.0(+0x246b1) [0x7fdd4f73f6b1]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x7e6) [0x7fdd4f7412a6]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_by_name+0x208) [0x7fdd4f7415f8]
/usr/lib/libgtk-x11-2.0.so.0(+0x1a5138) [0x7fdd50854138]
/usr/lib/libgtk-x11-2.0.so.0(+0x85967) [0x7fdd50734967]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0xa9) [0x7fdd4f7299b9]
/usr/lib/libgobject-2.0.so.0(+0x246b1) [0x7fdd4f73f6b1]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x7e6) [0x7fdd4f7412a6]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_by_name+0x208) [0x7fdd4f7415f8]
/usr/lib/libgtk-x11-2.0.so.0(+0x1a5138) [0x7fdd50854138]
/usr/lib/libgtk-x11-2.0.so.0(+0x26156c) [0x7fdd5091056c]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x15e) [0x7fdd4f729a6e]
/usr/lib/libgobject-2.0.so.0(+0x246b1) [0x7fdd4f73f6b1]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x7e6) [0x7fdd4f7412a6]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_by_name+0x208) [0x7fdd4f7415f8]
/usr/lib/libgtk-x11-2.0.so.0(+0x1a5138) [0x7fdd50854138]
/usr/lib/libgtk-x11-2.0.so.0(+0x2618c1) [0x7fdd509108c1]
/usr/lib/libgtk-x11-2.0.so.0(+0x26b4b9) [0x7fdd5091a4b9]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x15e) [0x7fdd4f729a6e]
/usr/lib/libgobject-2.0.so.0(+0x246b1) [0x7fdd4f73f6b1]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x7e6) [0x7fdd4f7412a6]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x83) [0x7fdd4f741863]
/usr/lib/libgtk-x11-2.0.so.0(gtk_widget_show+0x8b) [0x7fdd50909e8b]
/usr/lib/libgtk-x11-2.0.so.0(gtk_dialog_run+0x218) [0x7fdd50768718]
/usr/local/lib/libwx_gtk2u_core-2.8.so.0(_ZN15wxMessageDialog9ShowModalEv+0x4a) [0x7fdd516a8e8a]
/usr/local/lib/libwx_gtk2u_core-2.8.so.0(_Z12wxMessageBoxRK8wxStringS1_lP8wxWindowii+0x52) [0x7fdd516244c2]
/usr/local/lib/libwx_gtk2u_core-2.8.so.0(_ZN8wxLogGui5FlushEv+0x279) [0x7fdd517666a9]
/usr/local/lib/libwx_baseu-2.8.so.0(_ZN5wxLog15SetActiveTargetEPS_+0x27) [0x7fdd50d6e967]
/usr/local/lib/site_ruby/1.9.1/x86_64-linux/wxruby2.so(+0x40f6ec) [0x7fdd5335c6ec]
/usr/lib/libruby-1.9.1.so.1.9(+0x147258) [0x7fdd55315258]
/usr/lib/libruby-1.9.1.so.1.9(+0x13f410) [0x7fdd5530d410]
/usr/lib/libruby-1.9.1.so.1.9(+0x143e31) [0x7fdd55311e31]
/usr/lib/libruby-1.9.1.so.1.9(+0x14611f) [0x7fdd5531411f]
/usr/lib/libruby-1.9.1.so.1.9(rb_class_new_instance+0x30) [0x7fdd55267e20]
/usr/lib/libruby-1.9.1.so.1.9(+0x147258) [0x7fdd55315258]
/usr/lib/libruby-1.9.1.so.1.9(+0x13f410) [0x7fdd5530d410]
/usr/lib/libruby-1.9.1.so.1.9(+0x143e31) [0x7fdd55311e31]
/usr/lib/libruby-1.9.1.so.1.9(+0x14611f) [0x7fdd5531411f]
/usr/lib/libruby-1.9.1.so.1.9(rb_funcall+0x207) [0x7fdd55309fa7]
/usr/local/lib/site_ruby/1.9.1/x86_64-linux/wxruby2.so(_ZN9wxRubyApp6OnInitEv+0x52) [0x7fdd53155592]
/usr/local/lib/libwx_baseu-2.8.so.0(_Z7wxEntryRiPPw+0x64) [0x7fdd50d62ab4]
/usr/local/lib/site_ruby/1.9.1/x86_64-linux/wxruby2.so(+0x206970) [0x7fdd53153970]
/usr/lib/libruby-1.9.1.so.1.9(+0x147258) [0x7fdd55315258]
/usr/lib/libruby-1.9.1.so.1.9(+0x13f410) [0x7fdd5530d410]
/usr/lib/libruby-1.9.1.so.1.9(+0x143e31) [0x7fdd55311e31]
/usr/lib/libruby-1.9.1.so.1.9(rb_iseq_eval_main+0xb2) [0x7fdd55312082]
/usr/lib/libruby-1.9.1.so.1.9(+0x5bd52) [0x7fdd55229d52]
/usr/lib/libruby-1.9.1.so.1.9(ruby_exec_node+0x1d) [0x7fdd55229d7d]
/usr/lib/libruby-1.9.1.so.1.9(ruby_run_node+0x1e) [0x7fdd5522b63e]
ruby1.9.1(main+0x4b) [0x40092b]
/lib/libc.so.6(__libc_start_main+0xfe) [0x7fdd54384d8e]
ruby1.9.1() [0x400819]

$ lsb_release -rd
Description: Ubuntu 10.10
Release: 10.10

[Marvin Gülker (sutniuq)]

I've been experiencing the same problems on an Ubuntu as well as on an Arch Linux box. With pixman 0.20.0 installed, everything works fine (on Arch), but the next release 0.20.2 causes wxRuby to crash.

Oh and this one:

> 2. Install the wxWidgets gem: sudo gem1.9.1 install wxruby

will crash anyway because it will install the wxRuby gem for Ruby 1.8. I think the OP meant this:

> 2. Install the WxRuby gem: sudo gem1.9.1 install wxruby-ruby19

Valete,
Marvin

[bugbot (bugbot)]

Hey David,

Hi, have you had a chance to test if this bug is still present in natty?

If it does (and if you're the original reporter), please boot into natty
and run the command:

  apport-collect <bug-number>

which will update the bug with fresh logs and tag the bug as affecting
natty. (It is best to run this right after reproducing the problem.)

[Marvin Gülker (sutniuq)]

> Hi, have you had a chance to test if this bug is still present in natty?

This cannot be tested easily--the bug #632984 prevents this. Is there a way in Launchpad to mark that one as "must be solved before"?

Valete,
Marvin

[Raedwulf (tcmreastwood-gmail)]

I've found out what causes this bug; I found this bug not in wxRuby, but in wxLua---but its the same bug, using pixman 0.20.0 seems to fix it.

The offending commit (after trying each commit from 0.20.0 to 0.20.2 is:
http://cgit.freedesktop.org/pixman/commit/?h=0.20&id=6718621c62ef03d1dd71c34242a873aba798e8aa

Yes, its a fix that broke it :P. After going through what it does, it basically enables support for __thread if the compiler supports it, and in this case gcc *does* support it.

However, it looks like there's either a bug with the gcc __thread implementation, or how pixman uses __thread. Previously, such functionality looks like it would have defaulted to a pthread implementation.

Looks like this needs to be pushed upstream (somewhere), because the same bug exists up to the current HEAD and disabling __thread support fixes it.

[David Beswick (dlbeswick)]

This bug seems to be also occurring for GNUstep in Debian and Ubuntu. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613221

[David Beswick (dlbeswick)]

I re-tested this in Natty and it still happened. But going off the suggestion in that bug, I recompiled wxruby while excluding GLCanvas, and I found the problem doesn't occur, wxruby works fine. Maybe the issue is in Mesa as the bug suggests.

[Raedwulf (tcmreastwood-gmail)]

David, I'm running proprietary Nvidia drivers, don't think I'm using Mesa ;).

[David F. (malteworld)]

I can confirm David Beswick's findings and add a few details.

I experience this bug with versions 0.20.2, 0.22.0 and 0.23.1 (from today's git
master). Please have a look at my attached gdb trace (pixman git master on
Ubuntu 11.04 x86_64, all optimizations disabled (./configure --disable-openmp
--disable-mmx --disable-sse2 --disable-vmx --disable-arm-simd
--disable-arm-neon CFLAGS='-g -O0')).
The interesting parts are:

[...]
#0 0x00007fffea9b64d3 in lookup_composite_function (op=PIXMAN_OP_SRC,
src=0xf93b80, mask=0x0, dest=0xf93fb0, src_x=0, src_y=0, mask_x=0, mask_y=0,
dest_x=0, dest_y=0, width=8, height=1) at ../../pixman/pixman.c:378
        info = 0x8
[...]
rax 0x8 8
[...]
=> 0x7fffea9b64d3 <pixman_image_composite32+883>: mov (%rax),%eax

The corresponding part in pixman/pixman.c:378 is:

369 for (i = 0; i < N_CACHED_FAST_PATHS; ++i)
    {
    const pixman_fast_path_t *info = &(cache->cache[i].fast_path);

    /* Note that we check for equality here, not whether
     * the cached fast path matches. This is to prevent
     * us from selecting an overly general fast path
     * when a more specific one would work.
     */
378 if (info->op == op &&
        info->src_format == src_format &&
        info->mask_format == mask_format &&
        info->dest_format == dest_format &&
        info->src_flags == src_flags &&
        info->mask_flags == mask_flags &&
        info->dest_flags == dest_flags &&
        info->func)
    {
        *out_imp = cache->cache[i].imp;
        *out_func = cache->cache[i].fast_path.func;

        goto update_cache;
    }
392 }

So in line 378 pixman tries to read from a bad pointer.

When I comment that code part, everything seems fine.

[David F. (malteworld)]

In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613221 people suspect, this is related to a bogus TLS initialisation (in another library).

[Florian Fleissner (flo-j)]

I am also severely affected by this bug in Natty and desperately looking at least for a workaround. Below there is a stack trace of my simple gtk-application crashing in pixman_image_composite32() - I'm not sure if that helps. I would really appreciate a fix of libpixman-1-0 for Natty.

pixman_image_composite32
      in /usr/lib/libpixman-1.so.0 at [0x7f57597aea60]
pixman_image_composite32
      in /usr/lib/libpixman-1.so.0 at [0x7f57597aea60]
/usr/lib/libcairo.so.2(+0x3b98a)[0x7f5764a6898a]
/usr/lib/libcairo.so.2(+0x3cbc7)[0x7f5764a69bc7]
/usr/lib/libcairo.so.2(+0x6a83c)[0x7f5764a9783c]
/usr/lib/libcairo.so.2(+0x48b00)[0x7f5764a75b00]
/usr/lib/libcairo.so.2(+0x4c515)[0x7f5764a79515]
/usr/lib/libcairo.so.2(+0x4c866)[0x7f5764a79866]
/usr/lib/libcairo.so.2(+0x49181)[0x7f5764a76181]
/usr/lib/libcairo.so.2(+0x22ec0)[0x7f5764a4fec0]
cairo_fill_preserve
      in /usr/lib/libcairo.so.2 at [0x7f5764a46c50]
cairo_fill
      in /usr/lib/libcairo.so.2 at [0x7f5764a46c69]
Oxygen::StyleHelper::verticalGradient(Oxygen::ColorUtils::Rgba const&, int)
      in /usr/lib/gtk-2.0/2.10.0/engines/liboxygen-gtk.so at [0x7f575382b733]
Oxygen::Style::renderWindowBackground(_cairo*, _GdkDrawable*, _GtkWidget*, _GdkRectangle*, int, int, int, int, Oxygen::StyleOptions const&, Oxygen::Flags<Oxygen::TileSet::Tile>)
      in /usr/lib/gtk-2.0/2.10.0/engines/liboxygen-gtk.so at [0x7f57538082ef]
/usr/lib/gtk-2.0/2.10.0/engines/liboxygen-gtk.so(+0xc1955)[0x7f5753842955]
/usr/lib/libgtk-x11-2.0.so.0(+0x263606)[0x7f5764f51606]
/usr/lib/libgtk-x11-2.0.so.0(+0x268e8c)[0x7f5764f56e8c]
Gtk::Widget_Class::realize_callback(_GtkWidget*)
      in /usr/lib/libgtkmm-2.4.so.1 at [0x7f5763ddf76d]
g_closure_invoke
      in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 at [0x7f576581281c]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x1f7e3)[0x7f57658237e3]
g_signal_emit_valist
      in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 at [0x7f576582d258]
g_signal_emit
      in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 at [0x7f576582d41f]
gtk_widget_realize
      in /usr/lib/libgtk-x11-2.0.so.0 at [0x7f5764f4929e]
/usr/lib/libgtk-x11-2.0.so.0(+0x2658d8)[0x7f5764f538d8]
Gtk::Widget_Class::show_callback(_GtkWidget*)
      in /usr/lib/libgtkmm-2.4.so.1 at [0x7f5763ddf9ed]
g_closure_invoke
      in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 at [0x7f576581281c]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x1f7e3)[0x7f57658237e3]
g_signal_emit_valist
      in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 at [0x7f576582d258]
g_signal_emit
      in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 at [0x7f576582d41f]
gtk_widget_show
      in /usr/lib/libgtk-x11-2.0.s...