[Bug symtab/16902] New: GDB use-after-free segfault when loading certain program's debug symbols

[Bug symtab/16902] New: GDB use-after-free segfault when loading certain program's debug symbols

[antispam at idupree dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16902

            Bug ID: 16902
           Summary: GDB use-after-free segfault when loading certain
                    program's debug symbols
           Product: gdb
           Version: 7.7
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: antispam at idupree dot com

Platform: x86_64 Arch Linux, GCC 4.9.0.
(I've seen a similar issue with clang + gdb + this code.  However older GCC
versions often made object code that gdb'ed correctly, IIRC.)

I reproduced this bug with GDB 7.7 and git master as of 2014 May 4.

Steps to reproduce:

(1) obtain the inferior binary (Lasercake, a program I co-create) by either
downloading a test binary from
https://idupree.s3.amazonaws.com/misc-uploads/Lasercake-binary-for-gdb-bug-report
or by building from source:

$ git clone https://github.com/Lasercake/Lasercake
$ cd Lasercake
$ git checkout 6e04e885972f8
$ ./dev-build.py

(2) 
$ gdb Lasercake
(gdb) run --version

or `start` instead of `run`, which will make the failure more obvious.

GDB segfaults when I `run` or `start` this binary.  (The --version flag is just
to keep Lasercake from doing anything interesting; it doesn't affect the bug.)

I tried to make a smaller test case but all my attempts failed to reproduce the
GDB bug.  Lasercake's code uses C++11 heavily, Qt, and OpenGL via GLEW. 
Stripping debug symbols from the binary makes GDB work properly.

Possibly related bugs:
https://sourceware.org/bugzilla/show_bug.cgi?id=16426
https://sourceware.org/bugzilla/show_bug.cgi?id=14963

Stack traces (from GDB 7.7 with and without AddressSanitizer) are below.  I
also tried running GDB within valgrind, but `valgrind gdb` produces lots of
output even on normally working code.  Additionally, running gdb in valgrind
made gdb no longer segfault (which makes `valgrind --log-file=/dev/null gdb` a
hilarious workaround to the fact that I can't debugger Lasercake).

Stack trace from GDB 7.7:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff655d696 in __strcmp_ssse3 () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff655d696 in __strcmp_ssse3 () from /usr/lib/libc.so.6
#1  0x000000000054e1ef in eq_demangled_name_entry (a=<optimized out>,
b=<optimized out>)
    at symtab.c:596
#2  0x00000000006f97b2 in htab_find_slot_with_hash (htab=0xdf7450, 
    element=element@entry=0x7fffffffda70, hash=1061512100,
insert=insert@entry=INSERT)
    at ./hashtab.c:660
#3  0x00000000006f99d6 in htab_find_slot (htab=<optimized out>, 
    element=element@entry=0x7fffffffda70, insert=insert@entry=INSERT) at
./hashtab.c:704
#4  0x000000000054f552 in symbol_set_names (gsymbol=gsymbol@entry=0x27fe528, 
    linkage_name=linkage_name@entry=0x7ffff5582870
"_ZTSN5boost16exception_detail19error_info_injectorINS_15program_options20multiple_occurrencesEEE",
len=len@entry=96, 
    copy_name=copy_name@entry=0, objfile=objfile@entry=0x202b3d0) at
symtab.c:844
#5  0x00000000005b30c6 in prim_record_minimal_symbol_full (name=<optimized
out>, 
    name_len=96, copy_name=0, address=6040256, ms_type=mst_data,
section=<optimized out>, 
    objfile=0x202b3d0) at minsyms.c:945
#6  0x00000000004ef0d6 in elf_symtab_read (objfile=0x202b3d0, type=-178771856, 
    number_of_symbols=7334, symbol_table=0x21da900, copy_names=33731536) at
elfread.c:554
#7  0x00000000004ef83d in elf_symfile_read (objfile=0x202b3d0,
symfile_flags=-178771856)
    at elfread.c:1163
#8  0x000000000055a879 in read_symbols (objfile=objfile@entry=0x202b3d0, 
    add_flags=add_flags@entry=12) at symfile.c:838
#9  0x000000000055a46e in syms_from_objfile_1 (add_flags=12, addrs=0xe639e0, 
    objfile=0x202b3d0) at symfile.c:1013
#10 syms_from_objfile (add_flags=12, addrs=0xe639e0, objfile=0x202b3d0) at
symfile.c:1029
#11 symbol_file_add_with_addrs (abfd=abfd@entry=0xd29700, 
    name=name@entry=0x1154270
"/Users/me/projects/lasercake/Lasercake/Lasercake", 
    add_flags=add_flags@entry=12, addrs=addrs@entry=0x0, flags=flags@entry=0, 
    parent=parent@entry=0x0) at symfile.c:1126
#12 0x000000000055a954 in symbol_file_add_from_bfd (parent=0x0, flags=0,
addrs=0x0, 
    add_flags=12, name=0x1154270
"/Users/me/projects/lasercake/Lasercake/Lasercake", 
    abfd=0xd29700) at symfile.c:1215
#13 symbol_file_add (
    name=name@entry=0x1154270
"/Users/me/projects/lasercake/Lasercake/Lasercake", 
    add_flags=12, addrs=addrs@entry=0x0, flags=flags@entry=0) at symfile.c:1230
#14 0x000000000056b5f3 in follow_exec (
    execd_pathname=0x1154270
"/Users/me/projects/lasercake/Lasercake/Lasercake", pid=...)
    at infrun.c:931
#15 0x0000000000571577 in handle_inferior_event (ecs=0x7fffffffded0) at
infrun.c:3696
#16 0x0000000000572f72 in wait_for_inferior () at infrun.c:2776
#17 0x00000000005732a6 in proceed (addr=<optimized out>, 
    siggnal=siggnal@entry=GDB_SIGNAL_0, step=step@entry=0) at infrun.c:2331
#18 0x0000000000568f31 in run_command_1 (args=0xb7d136 "--version", 
    from_tty=<optimized out>, tbreak_at_main=<optimized out>) at infcmd.c:610
#19 0x0000000000632c6f in execute_command (p=<optimized out>, p@entry=0xb7d130
"", 
    from_tty=1) at top.c:468
#20 0x0000000000586ed5 in command_handler (command=0xb7d130 "") at
event-top.c:435
#21 0x0000000000587464 in command_line_handler (rl=<optimized out>) at
event-top.c:632
#22 0x00007ffff7bbf80e in rl_callback_read_char () from
/usr/lib/libreadline.so.6
#23 0x0000000000586f39 in rl_callback_read_char_wrapper (client_data=<optimized
out>)
    at event-top.c:164
#24 0x0000000000585bc1 in process_event () at event-loop.c:342
#25 0x0000000000585f77 in gdb_do_one_event () at event-loop.c:406
#26 0x000000000058618e in start_event_loop () at event-loop.c:431
#27 0x000000000057fee3 in captured_command_loop (data=data@entry=0x0) at
main.c:267
#28 0x000000000057e19a in catch_errors (func=func@entry=0x57fed0
<captured_command_loop>, 
    func_args=func_args@entry=0x0, errstring=errstring@entry=0x719719 "", 
    mask=mask@entry=RETURN_MASK_ALL) at exceptions.c:524
#29 0x0000000000580cc6 in captured_main (data=data@entry=0x7fffffffe370) at
main.c:1067
#30 0x000000000057e19a in catch_errors (func=func@entry=0x580220
<captured_main>, 
    func_args=func_args@entry=0x7fffffffe370,
errstring=errstring@entry=0x719719 "", 
    mask=mask@entry=RETURN_MASK_ALL) at exceptions.c:524
#31 0x0000000000581064 in gdb_main (args=args@entry=0x7fffffffe370) at
main.c:1076
#32 0x0000000000453f3e in main (argc=<optimized out>, argv=<optimized out>) at
gdb.c:34



Stack trace from GDB-7.7-compiled-with-AddressSanitizer:

(gdb) start --version
Temporary breakpoint 1 at 0x488710: file
/Users/me/projects/lasercake/Lasercake/main.cpp, line 400.
Starting program: /Users/me/projects/lasercake/Lasercake/Lasercake --version
process 7007 is executing new program:
/Users/me/projects/lasercake/Lasercake/Lasercake
=================================================================
==7005==ERROR: AddressSanitizer: heap-use-after-free on address 0x62100bfe48e0
at pc 0x7fe778b0395d bp 0x7fffc35007a0 sp 0x7fffc3500768
READ of size 1 at 0x62100bfe48e0 thread T0
    #0 0x7fe778b0395c in strcmp (/usr/lib/libasan.so.1+0x3695c)
    #1 0x732dc8 in eq_demangled_name_entry
/Users/me/modified/gdb-7.7/gdb/symtab.c:596
    #2 0xd11042 in htab_find_slot_with_hash hashtab.c:679
    #3 0xd111d4 in htab_find_slot hashtab.c:704
    #4 0x73401e in symbol_set_names /Users/me/modified/gdb-7.7/gdb/symtab.c:844
    #5 0x85ade0 in prim_record_minimal_symbol_full
/Users/me/modified/gdb-7.7/gdb/minsyms.c:945
    #6 0x604960 in record_minimal_symbol
/Users/me/modified/gdb-7.7/gdb/elfread.c:206
    #7 0x6064b4 in elf_symtab_read /Users/me/modified/gdb-7.7/gdb/elfread.c:554
    #8 0x609fd3 in elf_symfile_read
/Users/me/modified/gdb-7.7/gdb/elfread.c:1163
    #9 0x7568e4 in read_symbols /Users/me/modified/gdb-7.7/gdb/symfile.c:838
    #10 0x7575cb in syms_from_objfile_1
/Users/me/modified/gdb-7.7/gdb/symfile.c:1013
    #11 0x75760e in syms_from_objfile
/Users/me/modified/gdb-7.7/gdb/symfile.c:1029
    #12 0x757888 in symbol_file_add_with_addrs
/Users/me/modified/gdb-7.7/gdb/symfile.c:1126
    #13 0x757b78 in symbol_file_add_from_bfd
/Users/me/modified/gdb-7.7/gdb/symfile.c:1215
    #14 0x757bd3 in symbol_file_add
/Users/me/modified/gdb-7.7/gdb/symfile.c:1230
    #15 0x78fbc9 in follow_exec /Users/me/modified/gdb-7.7/gdb/infrun.c:931
    #16 0x797cdc in handle_inferior_event
/Users/me/modified/gdb-7.7/gdb/infrun.c:3696
    #17 0x794a6f in wait_for_inferior
/Users/me/modified/gdb-7.7/gdb/infrun.c:2776
    #18 0x793680 in proceed /Users/me/modified/gdb-7.7/gdb/infrun.c:2331
    #19 0x785337 in run_command_1 /Users/me/modified/gdb-7.7/gdb/infcmd.c:610
    #20 0x78541d in start_command /Users/me/modified/gdb-7.7/gdb/infcmd.c:643
    #21 0x56b33e in do_cfunc cli/cli-decode.c:107
    #22 0x573810 in cmd_func cli/cli-decode.c:1882
    #23 0xa29466 in execute_command /Users/me/modified/gdb-7.7/gdb/top.c:468
    #24 0x7d9ed4 in command_handler
/Users/me/modified/gdb-7.7/gdb/event-top.c:435
    #25 0x7dade8 in command_line_handler
/Users/me/modified/gdb-7.7/gdb/event-top.c:632
    #26 0x7fe7788b080d in rl_callback_read_char
(/usr/lib/libreadline.so.6+0x2d80d)
    #27 0x7d908b in rl_callback_read_char_wrapper
/Users/me/modified/gdb-7.7/gdb/event-top.c:164
    #28 0x7d9c33 in stdin_event_handler
/Users/me/modified/gdb-7.7/gdb/event-top.c:375
    #29 0x7d681d in handle_file_event
/Users/me/modified/gdb-7.7/gdb/event-loop.c:768
    #30 0x7d4ed3 in process_event
/Users/me/modified/gdb-7.7/gdb/event-loop.c:342
    #31 0x7d4fe9 in gdb_do_one_event
/Users/me/modified/gdb-7.7/gdb/event-loop.c:406
    #32 0x7d50bf in start_event_loop
/Users/me/modified/gdb-7.7/gdb/event-loop.c:431
    #33 0x7d90bd in cli_command_loop
/Users/me/modified/gdb-7.7/gdb/event-top.c:179
    #34 0x7c1b08 in current_interp_command_loop
/Users/me/modified/gdb-7.7/gdb/interps.c:327
    #35 0x7c45ce in captured_command_loop
/Users/me/modified/gdb-7.7/gdb/main.c:267
    #36 0x7bd653 in catch_errors
/Users/me/modified/gdb-7.7/gdb/exceptions.c:524
    #37 0x7c6c38 in captured_main /Users/me/modified/gdb-7.7/gdb/main.c:1067
    #38 0x7bd653 in catch_errors
/Users/me/modified/gdb-7.7/gdb/exceptions.c:524
    #39 0x7c6ce2 in gdb_main /Users/me/modified/gdb-7.7/gdb/main.c:1076
    #40 0x455297 in main /Users/me/modified/gdb-7.7/gdb/gdb.c:34
    #41 0x7fe776f42fff in __libc_start_main (/usr/lib/libc.so.6+0x1ffff)
    #42 0x455098 (/Users/me/modified/gdb-7.7-inst/bin/gdb+0x455098)

0x62100bfe48e0 is located 3040 bytes inside of 4064-byte region
[0x62100bfe3d00,0x62100bfe4ce0)
freed by thread T0 here:
    #0 0x7fe778b21907 in __interceptor_free (/usr/lib/libasan.so.1+0x54907)
    #1 0xaab806 in xfree common/common-utils.c:108
    #2 0x7fe776fa3dc4 in _obstack_free (/usr/lib/libc.so.6+0x80dc4)

previously allocated by thread T0 here:
    #0 0x7fe778b21b1f in malloc (/usr/lib/libasan.so.1+0x54b1f)
    #1 0xaab6bd in xmalloc common/common-utils.c:51
    #2 0x7fe776fa3d05 in _obstack_newchunk (/usr/lib/libc.so.6+0x80d05)

SUMMARY: AddressSanitizer: heap-use-after-free ??:0 strcmp
Shadow bytes around the buggy address:
  0x0c42817f48c0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c42817f48d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c42817f48e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c42817f48f0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c42817f4900: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0c42817f4910: fd fd fd fd fd fd fd fd fd fd fd fd[fd]fd fd fd
  0x0c42817f4920: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c42817f4930: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c42817f4940: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c42817f4950: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c42817f4960: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Contiguous container OOB:fc
  ASan internal:           fe
==7005==ABORTING
Lasercake 0.22.1                                                                
built on May  4 2014 by g++ (GCC) 4.9.0
for x86_64-unknown-linux-gnu with 8-byte pointers

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/16902] GDB use-after-free segfault when loading certain program's debug symbols

[antispam at idupree dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16902

--- Comment #1 from Isaac Dupree <antispam at idupree dot com> ---
If I compile Lasercake with -gstabs, this makes the gdb segfault go away.  -g
and -g1 each lead to gdb segfault.  -g0: no segfault.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/16902] GDB use-after-free segfault when loading certain program's debug symbols

[antispam at idupree dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16902

--- Comment #2 from Isaac Dupree <antispam at idupree dot com> ---
You can also build my code with CMake directly, e.g.: `cd Lasercake; mkdir
builddir; cd builddir; cmake ..; make VERBOSE=1` (VERBOSE=1 lets you see the
gcc command lines.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/16902] GDB use-after-free segfault when loading certain program's debug symbols

[antispam at idupree dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16902

--- Comment #3 from Isaac Dupree <antispam at idupree dot com> ---
To specify a compiler to build Lasercake, pass
    -DCMAKE_C_COMPILER=/path/to/cc -DCMAKE_CXX_COMPILER=/path/to/c++
to cmake or ./dev-build.py.  To specify compiler flags likewise,
    -DCFLAGS='-g -O2'
sets these for both C and C++.
(unfortunately cmake's usual -DCMAKE_C(XX)_FLAGS goes earlier in the compiler
command-line than values specified in CMakeLists.txt, so it doesn't work as
well).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/16902] GDB use-after-free segfault when loading certain program's debug symbols

[tromey at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16902

Tom Tromey <tromey at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at redhat dot com

--- Comment #4 from Tom Tromey <tromey at redhat dot com> ---
Sounds like the bug this patch fixes:

https://sourceware.org/ml/gdb-patches/2014-06/msg00550.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/16902] GDB use-after-free segfault when loading certain program's debug symbols

[antispam at idupree dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16902

--- Comment #5 from Isaac Dupree <antispam at idupree dot com> ---
I confirm that that patch (applied to today's git tree) fixes this issue for
me.
-Isaac

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/16902] GDB use-after-free segfault when loading certain program's debug symbols

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16902

--- Comment #6 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  34a68019ccc3879801a291a00bad5bc10558bf5d (commit)
      from  334ac421efca80df2f95960d917ea9cb5823fb18 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=34a68019ccc3879801a291a00bad5bc10558bf5d

commit 34a68019ccc3879801a291a00bad5bc10558bf5d
Author: Tom Tromey <tromey@redhat.com>
Date:   Mon Jun 16 03:17:19 2014 -0600

    fix memory errors with demangled name hash

    This fixes a regression that Jan pointed out.

    The bug is that some names were allocated by dwarf2read on the objfile
    obstack, but then passed to SYMBOL_SET_NAMES with copy_name=0.  This
    violates the invariant that the names must have a lifetime tied to the
    lifetime of the BFD.

    The fix is to allocate names on the per-BFD obstack.

    I looked at all callers, direct or indirect, of SYMBOL_SET_NAMES that
    pass copy_name=0.  Note that only the ELF and DWARF readers do this;
    other symbol readers were never updated (and perhaps cannot be,
    depending on the details of the formats).  This is why the patch is
    relatively small.

    Built and regtested on x86-64 Fedora 20.

    2014-06-26  Tom Tromey  <tromey@redhat.com>

        PR symtab/16902:
        * dwarf2read.c (fixup_go_packaging, dwarf2_compute_name)
        (dwarf2_physname, read_partial_die)
        (guess_partial_die_structure_name, fixup_partial_die)
        (guess_full_die_structure_name, anonymous_struct_prefix)
        (dwarf2_name): Use per-BFD obstack.

-----------------------------------------------------------------------

Summary of changes:
 gdb/ChangeLog    |    9 ++++++++
 gdb/dwarf2read.c |   58 ++++++++++++++++++++++++++++++++---------------------
 2 files changed, 44 insertions(+), 23 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/16902] GDB use-after-free segfault when loading certain program's debug symbols

[tromey at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16902

Tom Tromey <tromey at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |7.8

--- Comment #7 from Tom Tromey <tromey at redhat dot com> ---
Fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/16902] GDB use-after-free segfault when loading certain program's debug symbols

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16902

--- Comment #8 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, gdb-7.8-branch has been updated
       via  de73a7620bc6c00d05ce0e08df15bd316ca5d9a7 (commit)
      from  09d9aa647826f5ad96db8056eac67b214c892ae2 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=de73a7620bc6c00d05ce0e08df15bd316ca5d9a7

commit de73a7620bc6c00d05ce0e08df15bd316ca5d9a7
Author: Tom Tromey <tromey@redhat.com>
Date:   Mon Jun 16 03:17:19 2014 -0600

    fix memory errors with demangled name hash

    This fixes a regression that Jan pointed out.

    The bug is that some names were allocated by dwarf2read on the objfile
    obstack, but then passed to SYMBOL_SET_NAMES with copy_name=0.  This
    violates the invariant that the names must have a lifetime tied to the
    lifetime of the BFD.

    The fix is to allocate names on the per-BFD obstack.

    I looked at all callers, direct or indirect, of SYMBOL_SET_NAMES that
    pass copy_name=0.  Note that only the ELF and DWARF readers do this;
    other symbol readers were never updated (and perhaps cannot be,
    depending on the details of the formats).  This is why the patch is
    relatively small.

    Built and regtested on x86-64 Fedora 20.

    2014-06-26  Tom Tromey  <tromey@redhat.com>

        PR symtab/16902:
        * dwarf2read.c (fixup_go_packaging, dwarf2_compute_name)
        (dwarf2_physname, read_partial_die)
        (guess_partial_die_structure_name, fixup_partial_die)
        (guess_full_die_structure_name, anonymous_struct_prefix)
        (dwarf2_name): Use per-BFD obstack.

-----------------------------------------------------------------------

Summary of changes:
 gdb/ChangeLog    |    9 ++++++++
 gdb/dwarf2read.c |   58 ++++++++++++++++++++++++++++++++---------------------
 2 files changed, 44 insertions(+), 23 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.