[LLVMdev] Looking for a fix to memory leak in DWARF support

[Sergei Larin]

David,

Thanks for the quick response... 


No, at this point I am just getting into the issue... I assume it is a leak, but no clear proof yet. I was hoping it was an obvious thing since I recall a discussion about it a while ago... but maybe I am just confused.

Was your work for compressing DWARF data  motivated by a certain inefficiency in debug info representation? Did it result in significant savings?

Thanks.

Sergei

---
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation


> -----Original Message-----
> From: David Blaikie [mailto:dblaikie at gmail.com]
> Sent: Friday, June 13, 2014 12:41 PM
> To: Sergei Larin
> Cc: LLVM Developers Mailing List
> Subject: Re: Looking for a fix to memory leak in DWARF support
> 
> Are you sure it's a leak, not just a large memory footprint?
> 
> A lot of things have changed. Heck, even the bugs that we've fixed might not
> have existed two years ago (I've certainly created (and
> fixed) my share of bugs in debug info).
> 
> Best you start with a leak tracking tool and at least be able to point to the
> major leak culprit (eg: "90% of the leaked memory was allocated at <stack
> trace>")
> 
> On Fri, Jun 13, 2014 at 9:16 AM, Sergei Larin <slarin at codeaurora.org> wrote:
> >
> > David, (and everyone else)
> >
> >   I am forced to do some maintenance work on a fairly old LLVM branch
> > (likely based on release 3.1) that among other issues has a major
> > problem with memory leak somewhere around DWARF debug support.
> > In fact customer is unable to build with -g at all - simply running
> > out of memory on their project...
> >
> >   I seem to remember that there has been a major fix related to it,
> > but finding it hard to pinpoint. So the appeal to the communal memory
> > - do you remember if  there was a single fix (since the middle of 2012
> > or so) that would have addressed such issue?
> >
> >   I know the code was drastically change since - I have seen this for
> > instance
> > llvm.org/viewvc/llvm-project/llvm/trunk/lib/MC/ELFObjectWriter.cpp?vie
> > w=log&
> > pathrev=205990
> >
> > ...but not sure this is what I am looking for, and whether there is
> > something less drastic than I can do to plug that leak.
> >
> > Any clue would be very much appreciated.
> >
> > Thanks.
> >
> > Sergei
> >
> > ---
> > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> > hosted by The Linux Foundation
> >