Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Jul 2014 14:19:53 -0500
From:      Bryan Venteicher <bryanv@daemoninthecloset.org>
To:        Mateusz Guzik <mjguzik@gmail.com>, suresh gumpula <gsuryacse7k@gmail.com>,  "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>
Subject:   Re: Allocation/free history
Message-ID:  <CAMo0n6RyaqvL6-60ZXL_J=gNppfxWUs88QCuYF9Z%2Bd=WXPtr7A@mail.gmail.com>
In-Reply-To: <20140728202156.GB9781@dft-labs.eu>
References:  <CAJOqHmgO55L-D0_7zpnC0jFR%2BY1KWBzFwQirPfknhNeHzd0asg@mail.gmail.com> <20140728191950.GA9781@dft-labs.eu> <CAJOqHmimJcU1HUhF8=JOOj64aY34uQsNvytnS7N1YL=qSx66hQ@mail.gmail.com> <20140728202156.GB9781@dft-labs.eu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 28, 2014 at 3:21 PM, Mateusz Guzik <mjguzik@gmail.com> wrote:

> On Mon, Jul 28, 2014 at 03:37:28PM -0400, suresh gumpula wrote:
> > Hi,
> >   I am aware of redone(9). I am talking about PC allocation history of
> > objects.   Do we have something like that ?
> >
>
> Well, redzone "remembers" allocation and free backtrace, but does not
> keep any further history. It is unclear for me if tracking entire
> history would be of much benefit (note that mere allocation instruction
> pointer is typically not really helpful and keeping bts for everything
> would be quite memory consumimg).
>
>
=E2=80=8BThe AIX kernel debugger can provide a history when and who allocat=
ed and
freed a piece of memory. In a previous life, this was very useful at times
to track down memory corruption issues. Stealing a random example from [1]:

(0)> xm -h 0x09410200 *Display debug xmalloc records associated with addr*
0B78DAB0: addr......... 09410200 req_size..... 128 freed unpinned
0B78DAB0: pid.......... 00043158 comm......... bcross
Trace during xmalloc()                  Trace during xmfree()
002329E4(.xmalloc+0000A8)               002328F0(.xmfree+0000FC)
00235CD4(.dlistadd+000040)              00234F04(.setbitmaps+0001BC)
00235520(.newblk+00006C)                00236894(.finicom+0001A4)

0B645120: addr......... 09410200 req_size..... 128 freed unpinned
0B645120: pid.......... 0007DCAC comm......... bcross
Trace during xmalloc()                  Trace during xmfree()
002329E4(.xmalloc+0000A8)               002328F0(.xmfree+0000FC)
00235CD4(.dlistadd+000040)              00236614(.logdfree+0001E8)
00236574(.logdfree+000148)              00236720(.finicom+000030)

[1] -
http://www.mouritzen.dk/aix-doc/en_US/a_doc_lib/aixprggd/kernextc/kdb_cmd17=
.htm



> > Thanks
> > Suresh
> >
> >
> > On Mon, Jul 28, 2014 at 3:19 PM, Mateusz Guzik <mjguzik@gmail.com>
> wrote:
> >
> > > On Mon, Jul 28, 2014 at 01:40:10PM -0400, suresh gumpula wrote:
> > > > Hi,
> > > >    Knowing the PC of an allocation is very usefull in debugging.
> Having
> > > the
> > > > PC hash table and storing the pc hash  either with an object itself=
(
> at
> > > the
> > > > end) or allocate an exra structure to hold the
> > > > hash index  help us find out who/where an object was allocated.   W=
e
> > > > already have something like this in our own operating system and ha=
s
> > > been a
> > > > useful thing in debugging.
> > > > BSD allocator uses power of 2, so storing at the end of an object
> might
> > > be
> > > > wasting lot of memory with large objects.
> > > >
> > > > It appears we don=E2=80=99t have something like this in current FBS=
D
> codeline and
> > > > would like to work on this ?  Any comments   please?
> > > >
> > > >
> > > > It would be something like below. 8 bytes at the end of each object
> has
> > > > fecepost which is usefull in finding overwrites and 2 hash indices
> to the
> > > > PC table to track allocation history.
> > > > (kgdb-amd64-7.4-87) x/40w 0xffffff153728b038
> > > > 0xffffff153728b038:     0xf6970a05      0x06cb7e0c      0x305a134a
> > > >  0x831c18bb
> > > > 0xc0000bed      0x134a2115
> > > >
> > > > 0xffffff153728b050:     0x85687ef8      0xffffffff      0x00000001
> > > >  0x83192201
> > > >                         0xc0000bed      0x1741143b
> > > >
> > >
> > > See redzone(9).
> > >
> > > --
> > > Mateusz Guzik <mjguzik gmail.com>
> > >
>
> --
> Mateusz Guzik <mjguzik gmail.com>
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org=
"
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMo0n6RyaqvL6-60ZXL_J=gNppfxWUs88QCuYF9Z%2Bd=WXPtr7A>