Bug 638682

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?

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{|}~...........|

Looking at how "heap all" prints its information. HeapAll has the 
following:

             size = chunk.chunksize()

...

            print ('%i: %s -> %s %s: %i bytes (%s)'
                   % (i, 
                      fmt_addr(chunk.as_address()),
                      fmt_addr(chunk.as_address()+size-1),
                      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?

(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. */

 
  ...snip...

}

s/gdb.heap/heap/g in the above

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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping