[Bug libc/27216] New: Illegally written memory chunk address and its value is not getting printed in core file

[Bug libc/27216] New: Illegally written memory chunk address and its value is not getting printed in core file

[hadkeakash4 at gmail dot com]

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

            Bug ID: 27216
           Summary: Illegally written memory chunk address and its value
                    is not getting printed in core file
           Product: glibc
           Version: 2.27
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: hadkeakash4 at gmail dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

When illegal memory write operation (write after free) get performed and code
fails it should provide address of illegally written memory chunk and its value
in core file for debugging purpose.

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

[Bug libc/27216] Illegally written memory chunk address and its value is not getting printed in core file

[carlos at redhat dot com]

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

Carlos O'Donell <carlos at redhat dot com> changed:

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

--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Akash Hadke from comment #0)
> When illegal memory write operation (write after free) get performed and
> code fails it should provide address of illegally written memory chunk and
> its value in core file for debugging purpose.

Could you please elaborate further on this?

1. Provide an example program.
2. Provide example output.
3. Describe data that should be written and under what conditions.

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

[Bug libc/27216] Illegally written memory chunk address and its value is not getting printed in core file

[schwab@linux-m68k.org]

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

--- Comment #2 from Andreas Schwab <schwab@linux-m68k.org> ---
You are looking for valgrind.

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

[Bug libc/27216] Illegally written memory chunk address and its value is not getting printed in core file

[hadkeakash4 at gmail dot com]

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

--- Comment #3 from Akash Hadke <hadkeakash4 at gmail dot com> ---
(In reply to Carlos O'Donell from comment #1)
> (In reply to Akash Hadke from comment #0)
> > When illegal memory write operation (write after free) get performed and
> > code fails it should provide address of illegally written memory chunk and
> > its value in core file for debugging purpose.
> 
> Could you please elaborate further on this?
> 
> 1. Provide an example program.

I tried below CPP code to reproduce the issue

typedef std::size_t Item;
const std::size_t nItemsWanted = 64 / sizeof (Item);
Item *const paItems1 = new Item [nItemsWanted];
{
    std::fill (paItems1, paItems1 + nItemsWanted, Item(0x8899AABBCCDDEEFF));
}
delete [] paItems1;
paItems1 [0] = 0x00214E414D544142;
Item *const paItems3 = new Item [nItemsWanted];
Item *const paItems4 = new Item [nItemsWanted];

> 2. Provide example output.

Above code failed and reproduce core file.
After debugging core file got below backtrace.

(gdb) bt
#0 0x00007ff12b8f8407 in _GI__libc_malloc (bytes=64) at
/usr/src/debug/glibc/2.27-r0/git/malloc/malloc.c:3068
#1 0x00007ff12c261b48 in operator new(unsigned long) () from
/usr/lib/libstdc++.so.6
#2 0x000055c2db586645 in main () at
/usr/src/debug/qtbase/5.6.2+gitAUTOINC+b4ada3f0d8-r0/Example-of-Buggy-Program-v2.cpp:22

(gdb) x/8gx e
Value can't be converted to integer.

But I am expecting below output.

(gdb) bt
#0 __malloc_tcache_walk (ptcache=0x55b28b3d0010, tc_idx=tc_idx@entry=3,
e=e@entry=0x55b28b3e1e70)
at /usr/src/debug/glibc/2.27-r0/git/malloc/malloc.c:2949
#1 0x00007f90e5abc53a in tcache_get (tc_idx=3) at
/usr/src/debug/glibc/2.27-r0/git/malloc/malloc.c:2984
#2 _GI__libc_malloc (bytes=64) at
/usr/src/debug/glibc/2.27-r0/git/malloc/malloc.c:3096
#3 0x00007f90e6425b48 in operator new(unsigned long) () from
/usr/lib/libstdc++.so.6
#4 0x000055b28a44263b in main () at
/usr/src/debug/qtbase/5.6.2+gitAUTOINC+b4ada3f0d8-r0/Example-of-Buggy-Program-v2.cpp:21

(gdb) x/8gx e
0x55b28b3e1e70: 0x00214e414d544142  0x000055b28b3d0010
0x55b28b3e1e80: 0x8899aabbccddeeff     0x8899aabbccddeeff
0x55b28b3e1e90: 0x8899aabbccddeeff     0x8899aabbccddeeff
0x55b28b3e1ea0: 0x8899aabbccddeeff     0x8899aabbccddeeff

Where it will show heap chunk and illegally written address and its value.

> 3. Describe data that should be written and under what conditions.

To improve the tracing in case of production issues.
We need traces from the production issues and its too complex to run the
valgrind at least in production cases.

I have suggested a patch for this.
http://patchwork.sourceware.org/project/glibc/patch/CAK0fB4M6pXPL9D1aL8TcpFGZDvjqoJrv93N_hDO26XHkVAkwAw@mail.gmail.com/

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

[Bug libc/27216] Illegally written memory chunk address and its value is not getting printed in core file

[carlos at redhat dot com]

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

--- Comment #4 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Akash Hadke from comment #3)
> To improve the tracing in case of production issues.
> We need traces from the production issues and its too complex to run the
> valgrind at least in production cases.
> 
> I have suggested a patch for this.
> http://patchwork.sourceware.org/project/glibc/patch/
> CAK0fB4M6pXPL9D1aL8TcpFGZDvjqoJrv93N_hDO26XHkVAkwAw@mail.gmail.com/

You are looking for increased observability in a production application.

You patch makes performance worse for every application in the world using
glibc malloc.

This is not a tradeoff that everyone else is going to agree is good for their
use cases.

You really need to use valgrind in a non-produciton reproducer of your problem.

==471344== Invalid write of size 8
==471344==    at 0x40119E: main (test.cpp:15)
==471344==  Address 0x4dc3c80 is 0 bytes inside a block of size 64 free'd
==471344==    at 0x483C59C: operator delete[](void*) (vg_replace_malloc.c:649)
==471344==    by 0x40118F: main (test.cpp:14)
==471344==  Block was alloc'd at
==471344==    at 0x483B582: operator new[](unsigned long)
(vg_replace_malloc.c:431)
==471344==    by 0x40114F: main (test.cpp:10)

Alternatively I would accept a discussion of adding a systemtap trace point to
the tcache that allows you to use a tracer in a production system to look for
such problems. This tracer would be a NOP unless activated.

Have you evaluated adding an addition trace point? Using systemtap to find this
and print a userspace backtrace could be beneficial.

Your suggested solution posted to libc-alpha is not acceptable given the
performance implications.

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

[Bug libc/27216] Illegally written memory chunk address and its value is not getting printed in core file

[schwab@linux-m68k.org]

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

--- Comment #5 from Andreas Schwab <schwab@linux-m68k.org> ---
When I try the example, I get this backtrace when it crashed.

#0  tcache_get (tc_idx=3) at malloc.c:2943
#1  __GI___libc_malloc (bytes=64) at malloc.c:3050
#2  0x00007ffff7aac039 in operator new (sz=sz@entry=64)
    at ../../../../libstdc++-v3/libsupc++/new_op.cc:50
#3  0x00007ffff7aac089 in operator new[] (sz=sz@entry=64)
    at ../../../../libstdc++-v3/libsupc++/new_opv.cc:32
#4  0x0000000000400765 in main () at uaf.cc:16

Looks like your compiler is just unable to generate useful debug information.

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