[LLVMdev] GSoC'09 question - previous mail w/o html

Bill Wendling isanbard at gmail.com
Sat Mar 28 17:56:29 PDT 2009


On Mar 28, 2009, at 1:34 AM, Mihai Balint wrote:

> On Mar 28, 2009, at 4:39 AM, Anthony Danalis wrote:
>> On Mar 27, 2009, at 9:15 PM, Dan Gohman wrote:
>>>
>>> On Mar 26, 2009, at 8:28 AM, Mihai Balint wrote:
>>>> This summer however, I plan to create an "optimization" that
>>>> automatically fixes memory leaks in programs - obviously only those
>>>> that can be fixed with the available information, for example:
>>>
>>> Hello,
>>>
>>> This doesn't sound advisable.  A memory leak in a normal C/C++
>>> program
>>> is a bug, so this wouldn't be an optimization -- it'd be a
>>> transformation that
>>> unreliably hides bugs.
>>>
>> It doesn't sound correct either.  I, for one, have a multithreaded
>> code where all "created" threads allocate "request" objects, put them
>> in a list and wake up the main thread.  The main thread on the other
>> hand sleeps, consumes requests, frees the objects it consumed and  
>> goes
>> back to sleep in a loop.  There is no path between the malloc() and
>> the free(), but that's how it is supposed to be, there is no leak.
>>
>
> You are right it's not an optimization, it is a bug-fixing
> transformation and I wasn't really planning on being totally silent
> and covert about anything I find (fixable or not).
>
This sounds more like something that could be added to the clang  
static analyzer ( http://clang.llvm.org/StaticAnalysis.html ). I'm not  
a big fan of the compiler changing the semantics of code that a  
programmer wrote. It's full of pitfalls. If, on the other hand, you  
can tell the programmer that there's the potential for a leak and let  
her determine if it's a "real" leak, that would be much better for all  
concerned.

> Regarding precision, without a minimum of real-world case studies not
> much can be said, but I will insert fix code only for allocations that
> do not escape (via returns, arguments, member fields or global
> variables) and are deleted on an viable alternate CFG path. Granted, I
> will loose some leaks but the ones I do find are likely fixable.
>
> I'll prepare a short project proposal with a summary of the approach
> and some expected goals, however this feels like research material and
> I don't know if it is eligible for GSoC funding....
>
Sounds good!

-bw



More information about the llvm-dev mailing list