Bug#740882: gir1.2-gdkpixbuf-2.0: Systematic segfault when trying to execute 'gnome-control-center background'

[Emmanuel Fleury]

On 03/06/2014 10:27 AM, Emilio Pozuelo Monfort wrote:
> reassign 740882 gnome-control-center
> forcemerge 739206 740882
> thanks
> 
> On 05/03/14 19:57, Emmanuel Fleury wrote:
>> Package: gir1.2-gdkpixbuf-2.0
>> Version: 2.30.5-1
>> Severity: important
>>
>> I have seen this behavior since my last update to 2.30.5 version on my
>> two machines. It is totally reproducible and occurs at each attempt.
> 
> Known bug. You can probably work-around it by setting the background through dconf.
> 
> As for the grey background, that's unrelated, also known. You can workaround it
> by disabling desktop icons.

In fact, I got a bit further. I had some time to install debug symbols
and carve a bit in the program.

Here is a more meaningful back-trace:


(gdb) bt
#0  convert_alpha (height=1080, width=1920, src_y=<optimized out>,
src_x=<optimized out>, src_stride=7680, src_data=0x11cdf00 "",
dest_stride=7680,
    dest_data=0x7fffbb89b210 "") at
/tmp/buildd/gtk+3.0-3.10.7/./gdk/gdkpixbuf-drawable.c:162
#1  gdk_pixbuf_get_from_surface (surface=0xfec350, src_x=<optimized
out>, src_y=<optimized out>, width=1920, height=1080)
    at /tmp/buildd/gtk+3.0-3.10.7/./gdk/gdkpixbuf-drawable.c:270
#2  0x000000000045a4bc in ?? ()
#3  0x00007ffff1c58a57 in g_simple_async_result_complete
(simple=0xe54ce0) at
/tmp/buildd/glib2.0-2.38.2/./gio/gsimpleasyncresult.c:777
#4  0x00007ffff1ca913a in g_dbus_connection_call_done (source=<optimized
out>, result=<optimized out>, user_data=0xd63d50)
    at /tmp/buildd/glib2.0-2.38.2/./gio/gdbusconnection.c:5490
#5  0x00007ffff1c58a57 in g_simple_async_result_complete
(simple=0xe54d50) at
/tmp/buildd/glib2.0-2.38.2/./gio/gsimpleasyncresult.c:777
#6  0x00007ffff1c58ab9 in complete_in_idle_cb (data=<optimized out>) at
/tmp/buildd/glib2.0-2.38.2/./gio/gsimpleasyncresult.c:789
#7  0x00007ffff0d48526 in g_main_dispatch (context=0x99b320) at
/tmp/buildd/glib2.0-2.38.2/./glib/gmain.c:3066
#8  g_main_context_dispatch (context=context at entry=0x99b320) at
/tmp/buildd/glib2.0-2.38.2/./glib/gmain.c:3642
#9  0x00007ffff0d48878 in g_main_context_iterate
(context=context at entry=0x99b320, block=block at entry=1,
dispatch=dispatch at entry=1, self=<optimized out>)
    at /tmp/buildd/glib2.0-2.38.2/./glib/gmain.c:3713
#10 0x00007ffff0d4891c in g_main_context_iteration (context=0x99b320,
context at entry=0x0, may_block=may_block at entry=1) at
/tmp/buildd/glib2.0-2.38.2/./glib/gmain.c:3774
#11 0x00007ffff1c84a1c in g_application_run (application=0x997100,
argc=1, argv=0x7fffffffe2a8) at
/tmp/buildd/glib2.0-2.38.2/./gio/gapplication.c:1635
#12 0x00000000004498c8 in main ()


The problem seems to occur in convert_alpha, but the stack is corrupted
in higher addresses (see level #2).

The reason of the segfault seems to be because convert_alpha iterate on
src_data which do not point toward real data.

Looking around at the position of the segfault leads to this loop:

   0x00007ffff219e870 <+432>:	movb   $0x0,(%rcx)
   0x00007ffff219e873 <+435>:	movb   $0x0,0x1(%rcx)
   0x00007ffff219e877 <+439>:	movb   $0x0,0x2(%rcx)
   0x00007ffff219e87b <+443>:	add    $0x1,%r8d
   0x00007ffff219e87f <+447>:	mov    %sil,0x3(%rcx)
   0x00007ffff219e883 <+451>:	add    $0x4,%rdi
   0x00007ffff219e887 <+455>:	add    $0x4,%rcx
   0x00007ffff219e88b <+459>:	cmp    %r8d,%ebp
   0x00007ffff219e88e <+462>:	jle    0x7ffff219e930
<gdk_pixbuf_get_from_surface+624>
=> 0x00007ffff219e894 <+468>:	mov    0x0(%r13,%rdi,1),%r9d
   0x00007ffff219e899 <+473>:	mov    %r9d,%esi
   0x00007ffff219e89c <+476>:	shr    $0x18,%esi
   0x00007ffff219e89f <+479>:	test   %esi,%esi
   0x00007ffff219e8a1 <+481>:	je     0x7ffff219e870
<gdk_pixbuf_get_from_surface+432>
   0x00007ffff219e8a3 <+483>:	mov    %r9d,%r11d


Investigating a bit around the crash

(gdb) p /x $r13
$1 = 0x11cdf00
(gdb) ptype *0x11cdf00
type = int
(gdb) p /x $rdi
$2 = 0x100 (256)

So, we are accessing an array of integers (32bits) that are moved to
%r9d (32bits).

The problem is that we are accessing one integer to far:

(gdb) p /x * (0x11cdf00+0xaa)
$3 = 0x0
(gdb) p /x * (0x11cdf00+0x100)
Cannot access memory at address 0x11ce000

I didn't take the time to link this to actual C code, but I hope this
help a bit.

Regards
-- 
Emmanuel Fleury

Ok, the patches look fine, but I somehow have this slight feeling that
you gave up a bit too soon on the '*why* does this happen?' question."
  -- Linus Torvalds