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. > > Dan >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. Anthony
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). 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.... best wishes, Mihai.
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