public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
* [PATCH] glibc: Apply patch for easy analysis of malloc issue
@ 2021-01-20 15:42 Akash Hadke
  2021-01-20 16:32 ` Carlos O'Donell
  0 siblings, 1 reply; 4+ messages in thread
From: Akash Hadke @ 2021-01-20 15:42 UTC (permalink / raw)
  To: libc-alpha; +Cc: akash.hadke, aditya.tayade

[-- Attachment #1: Type: text/plain, Size: 2250 bytes --]

The function __malloc_tcache_walk added in this patch provides
information of entire heap memory chunk in the core file.

This patch provides the address and value of the memory chunk illegally
written, which can help to understand and debug the issue.

Used below CPP code for testing purpose.

============================================================================
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];
============================================================================

This code fails and produce coredump below is the log of backtrace

Without proposed patch:
(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.

With proposed patch:
(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

ChangeLog:

2021-01-20 Akash Hadke <hadkeakash4@gmail.com>

[BZ #27216]

* malloc/malloc.c: Add new function __malloc_tcache_walk.

--

[-- Attachment #2: Patch-for-better-analysis-of-malloc-issue.patch --]
[-- Type: text/x-patch, Size: 3595 bytes --]

glibc: Patch for better Analysis of malloc issue

The function __malloc_tcache_walk added in this patch provides
information of entire heap memory chunk in the core file.

This patch provides address and value of the memory chunk illegally
written, which can help to understand and debug the issue.

Used below CPP code for testing purpose.

============================================================================
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];
============================================================================

This code fails and produce coredump below is the log of backtrace

Without proposed patch:
(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.

With proposed patch:
(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

Signed-off-by: Bogdan Dragu <Bogdan.Dragu@harman.com>
Signed-off-by: Akash Hadke <hadkeakash4@gmail.com>
Upstream-Status: Pending
---
--- a/malloc/malloc.c	2021-01-19 14:42:22.263863000 +0530
+++ b/malloc/malloc.c	2021-01-19 15:01:42.291811660 +0530
@@ -2924,6 +2924,25 @@
 static __thread bool tcache_shutting_down = false;
 static __thread tcache_perthread_struct *tcache = NULL;
 
+__thread size_t __malloc_tcache_t_dummy_count;
+
+const tcache_entry *
+__malloc_tcache_walk
+(const tcache_perthread_struct *ptcache, size_t tc_idx, const tcache_entry *e)
+{
+  const tcache_entry *const p0 = e->next;
+
+  const tcache_entry *      p  = p0;
+  {
+    for (size_t i = 0; p && i < 4; ++i)
+      p = p->next;
+  }
+
+  ++__malloc_tcache_t_dummy_count;
+
+  return p0;
+}
+
 /* Caller must ensure that we know tc_idx is valid and there's room
    for more chunks.  */
 static __always_inline void
@@ -2946,10 +2965,14 @@
 static __always_inline void *
 tcache_get (size_t tc_idx)
 {
-  tcache_entry *e = tcache->entries[tc_idx];
   assert (tc_idx < TCACHE_MAX_BINS);
-  assert (tcache->entries[tc_idx] > 0);
-  tcache->entries[tc_idx] = e->next;
+  tcache_entry *const e = tcache->entries[tc_idx];
+
+  tcache_entry *const e_next = (tcache_entry *) __malloc_tcache_walk (tcache, tc_idx, e);
+  assert (e_next == e->next);
+
+  tcache->entries[tc_idx] = e_next;
+
   --(tcache->counts[tc_idx]);
   e->key = NULL;
   return (void *) e;

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] glibc: Apply patch for easy analysis of malloc issue
  2021-01-20 15:42 [PATCH] glibc: Apply patch for easy analysis of malloc issue Akash Hadke
@ 2021-01-20 16:32 ` Carlos O'Donell
  2021-01-21  5:38   ` Akash Hadke
  0 siblings, 1 reply; 4+ messages in thread
From: Carlos O'Donell @ 2021-01-20 16:32 UTC (permalink / raw)
  To: Akash Hadke, libc-alpha; +Cc: akash.hadke, aditya.tayade

On 1/20/21 10:42 AM, Akash Hadke via Libc-alpha wrote:
> The function __malloc_tcache_walk added in this patch provides
> information of entire heap memory chunk in the core file.
> 
> This patch provides the address and value of the memory chunk illegally
> written, which can help to understand and debug the issue.

A developer would use valgrind to detect this issue.

Why is valgrind not sufficient for your use case?

-- 
Cheers,
Carlos.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] glibc: Apply patch for easy analysis of malloc issue
  2021-01-20 16:32 ` Carlos O'Donell
@ 2021-01-21  5:38   ` Akash Hadke
  2021-01-21  8:40     ` Andreas Schwab
  0 siblings, 1 reply; 4+ messages in thread
From: Akash Hadke @ 2021-01-21  5:38 UTC (permalink / raw)
  To: Carlos O'Donell; +Cc: libc-alpha, akash.hadke, aditya.tayade

Because valgrind didn't provide entire heap memory chunk and also it
doesn't show illegally written values. Which can be done using given patch.

On Wed, Jan 20, 2021 at 10:02 PM Carlos O'Donell <carlos@redhat.com> wrote:

> On 1/20/21 10:42 AM, Akash Hadke via Libc-alpha wrote:
> > The function __malloc_tcache_walk added in this patch provides
> > information of entire heap memory chunk in the core file.
> >
> > This patch provides the address and value of the memory chunk illegally
> > written, which can help to understand and debug the issue.
>
> A developer would use valgrind to detect this issue.
>
> Why is valgrind not sufficient for your use case?
>
> --
> Cheers,
> Carlos.
>
>

-- 
Akash Hadke

800-7474-400

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] glibc: Apply patch for easy analysis of malloc issue
  2021-01-21  5:38   ` Akash Hadke
@ 2021-01-21  8:40     ` Andreas Schwab
  0 siblings, 0 replies; 4+ messages in thread
From: Andreas Schwab @ 2021-01-21  8:40 UTC (permalink / raw)
  To: Akash Hadke via Libc-alpha
  Cc: Carlos O'Donell, Akash Hadke, akash.hadke, aditya.tayade

On Jan 21 2021, Akash Hadke via Libc-alpha wrote:

> Because valgrind didn't provide entire heap memory chunk and also it
> doesn't show illegally written values.

You can attach a debugger to inspect the failure.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-01-21  8:41 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-20 15:42 [PATCH] glibc: Apply patch for easy analysis of malloc issue Akash Hadke
2021-01-20 16:32 ` Carlos O'Donell
2021-01-21  5:38   ` Akash Hadke
2021-01-21  8:40     ` Andreas Schwab

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).