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

[David Blaikie]

On Fri, Jun 13, 2014 at 11:03 AM, Sergei Larin <slarin at codeaurora.org> wrote:
>
> 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.

There have been some memory leaks fixed - the discussion you might be
recalling is the frontend leaks using DIBuilder. Addressed by changes
like this: http://llvm.org/viewvc/llvm-project?rev=208055&view=rev

But I don't think that was ever a crippling bug, so far as I recall.
We only found this when using leak detectors - not when compiling vast
swathes of code, etc.

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

compressing DWARF has little to do with memory leaks, etc - it's
related to the nature of DWARF on disk, that's where the compression
occurs (in the object (and dwo) files themselves). Yes, it does have
substantial savings, though I don't have the numbers at hand right
now. (string sections especially are compressed well).

- David

>
> 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
>> >
>