How to work out why a data constructor is allocated using gdb?

[Matthew Pickering]

In the unlikely situation that anyone cares about this or attempts to
try to do it.  If you combine together `-prof` and `-debug` invoking
any heap profiling mode will take about `10x` longer than usual.

So you can still use `-prof` in order to populate the profiling
headers but don't also try to perform a heap census.

Cheers,

Matt


On Fri, Oct 4, 2019 at 4:57 PM Matthew Pickering
<matthewtpickering at gmail.com> wrote:
>
> It occurred to me today that in order to work out where a constructor
> is allocated from you can look in the profiling header.
>
> The profiling header contains information about the cost centre stack
> at the precise point of allocation. You should be able
> to look at this to see what the call stack was and the source position
> of the cost centre at the bottom of the stack.
>
> Cheers,
>
> Matt
>
> On Tue, Aug 13, 2019 at 8:29 AM Matthew Pickering
> <matthewtpickering at gmail.com> wrote:
> >
> > Hi,
> >
> > I am trying to work out questions such as
> >
> > * Why are there thousands of Module data constructors allocated when
> > building something with GHC
> > * What is allocating all a lot of strings when building GHC?
> >
> > In order to do this I can use gdb in order to find some of the
> > Module/String closures but then I'm a bit stuck about what to do.
> >
> > gdb displays a list of all the Module closures for example and then
> > you can usually try to find the retainer for Module by using findPtr.
> >
> > If the retainer is a THUNK closure, it would be easy, as THUNK
> > closures have DWARF information which maps straight to a particular
> > line. However if the retainer is just some other
> > data constructor, for example, the Module is stored in a Map, it's
> > data constructors all the way up and none of them have DWARF info. I
> > need to fall back to domain specific knowledge
> > to work out where such a sequence of constructors might appear in my program.
> >
> > * Is there anything better I can do to map a constructor allocation to
> > a more precise source location?
> >
> > The string closures were causing me some particular issues as
> > `findPtr` was not showing any retainers so it's hard to work out why
> > they are not GCd.
> >
> > * What situations can an object be retained but show no retainer when
> > using findPtr?
> >
> > Cheers,
> >
> > Matt