Bug 638682 - "heap all" output for systemtap looks wrong
"heap all" output for systemtap looks wrong
Product: Fedora
Classification: Fedora
Component: gdb-heap (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Dave Malcolm
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2010-09-29 12:13 EDT by William Cohen
Modified: 2012-08-16 14:02 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-08-16 14:02:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
pmap output of stap process (7.21 KB, text/plain)
2010-09-30 11:13 EDT, William Cohen
no flags Details

  None (edit)
Description William Cohen 2010-09-29 12:13:29 EDT
Description of problem:

When attempting to use gdb-heap on systemtap some of the output looked wrong.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.PYTHONPATH=/usr/share/gdb-heap gdb /usr/bin/stap
  python import heap
  break exit
  run -p4 -e 'probe vfs.read { printf("vfs.read\n"); exit(); }'
2. After program stops at break point, on gdb command line "heap all"

Actual results of "heap all":

All chunks of memory on heap (both used and free)
0: 0x00007ffff6516000 -> 0x00007ffff6516fff  inuse: 4096 bytes (<MChunkPtr chunk=0x7ffff6516000 mem=0x7ffff6516010 prev_size=0 IS_MMAPPED chunksize=4096 memsize=4080>)
1: 0x00007ffff6517000 -> 0x7675f47368c2e067  inuse: 8535856707940741224 bytes (<MChunkPtr chunk=0x7ffff6517000 mem=0x7ffff6517010 PREV_INUSE NON_MAIN_ARENA IS_MMAPPED chunksize=8535856707940741224 memsize=8535856707940741208>)

Expected results:

Not to have the bogus sized object:

1: 0x00007ffff6517000 -> 0x7675f47368c2e067  inuse: 8535856707940741224 bytes (<MChunkPtr chunk=0x7ffff6517000 mem=0x7ffff6517010 PREV_INUSE NON_MAIN_ARENA IS_MMAPPED chunksize=8535856707940741224 memsize=8535856707940741208>)

Additional info:
Comment 1 Dave Malcolm 2010-09-29 18:55:46 EDT
Thanks for filing this.

I'm able to reproduce this; not yet sure what's going wrong.

(gdb) python import heap
(gdb) python ms = heap.glibc.get_ms()
(gdb) python for i in ms.iter_mmap_chunks(): print i
<MChunkPtr chunk=0x7ffff6515000 mem=0x7ffff6515010 prev_size=0 IS_MMAPPED chunksize=4096 memsize=4080>
<MChunkPtr chunk=0x7ffff6516000 mem=0x7ffff6516010 PREV_INUSE NON_MAIN_ARENA IS_MMAPPED chunksize=8535856707940741224 memsize=8535856707940741208>

/proc/PID/maps has:
7ffff6515000-7ffff652a000 rw-p 00000000 00:00 0 

0x7ffff6515000 has size 4096 + 2 (for MMAP flag),
0x7ffff6516000 is in the middle of an ascending pattern of bytes

Is it really a malloc'ed block, or is this another mmap, I wonder?
Comment 2 William Cohen 2010-09-30 11:13:10 EDT
Created attachment 450785 [details]
pmap output of stap process

At some point some of the debuginfo should be mmaped, but that shouldn't been seen in the heap operations. The pmap shows the various memory regions. Entry 0 and 1 are in:

00007ffff6516000     84K rw---    [ anon ]

I did a search to see if there were any other large blocks. This seems to be the only one larger than 1,000,000

(gdb) heap select size > 1000000

             Start                 End         Domain  Kind                     Detail                                                                             Hexdump
------------------  ------------------  -------------  ----  -------------------------  ----------------------------------------------------------------------------------
0x00007ffff6517010  0x7675f47368c2e077  uncategorized        8535856707940741224 bytes  77 78 79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85 86 87 88 89 8a |wxyz{|}~...........|
Comment 3 William Cohen 2010-09-30 15:09:07 EDT
Looking at how "heap all" prints its information. HeapAll has the 

             size = chunk.chunksize()


            print ('%i: %s -> %s %s: %i bytes (%s)'
                   % (i, 
                      kind, size, chunk))

The methods called for chunk.chunksize():

   def chunksize(self):
        return self.size() & ~(self.SIZE_BITS)

    def size(self):
        if not(hasattr(self, '_cached_size')):
            self._cached_size = long(self.field('size'))
       return self._cached_size

Where is the self.field('size') coming from?
Comment 4 Dave Malcolm 2010-09-30 15:31:19 EDT
(In reply to comment #3)
> Where is the self.field('size') coming from?

"self" is a gdb.heap.WrappedPointer around a gdb.Value of type "mchunkptr".

The "self.field" method is a method of the gdb.heap.WrappedValue base class in heap/__init__.py:

    def field(self, attr):
        return self._gdbval[attr]

i.e. it's looking up the "size" field from a mchunkptr in the inferior process.

/usr/src/debug/glibc-*/malloc/malloc.c defines this as:
  struct malloc_chunk;
  typedef struct malloc_chunk* mchunkptr;

struct malloc_chunk {

  INTERNAL_SIZE_T      prev_size;  /* Size of previous chunk (if free).  */
  INTERNAL_SIZE_T      size;       /* Size in bytes, including overhead. */


Comment 5 Dave Malcolm 2010-09-30 15:32:09 EDT
s/gdb.heap/heap/g in the above
Comment 6 Fedora End Of Life 2012-08-16 14:02:26 EDT
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Note You need to log in before you can comment on or make changes to this bug.