Debugging memory leaks

[Giorgos Tzampanakis]

On 2013-06-14, Steven D'Aprano wrote:

> On Thu, 13 Jun 2013 20:15:42 +0000, Giorgos Tzampanakis wrote:
>
>>> Therefore: if the leak seems to be small, it may be much more advicable
>>> to restart your process periodically (during times where a restart does
>>> not hurt much) rather than try to find (and fix) the leaks. Only when
>>> the leak is large enough that it would force you to too frequent
>>> restarts, a deeper analysis may be advicable (large leaks are easier to
>>> locate as well).
>> 
>> 
>> Am I the only one who thinks this is terrible advice?
>
>
> Sub-optimal, maybe, but terrible? Not even close. Terrible advice would 
> be "open up all the ports on your firewall, that will fix it!"
>
> If it takes, say, 200 person-hours to track down this memory leak, and 
> another 200 person-hours to fix it, that's an awful large expense. In 
> that case, it would surely be better to live with the inconvenience and 
> mess of having a nightly/weekly/monthly reboot. On the other hand, maybe 
> it will only take 1 hour to find, and fix, the leak. Who knows?

But having a memory leak in the first place is an indication that
something is very wrong with your program. Either you're keeping
references that you didn't mean to be keeping (which indicates that there
can be larger side-effects than just wasted memory) or a linked C library
is leaking memory, which is bad for reasons which I won't cover here since
they are self-evident.


-- 
Real (i.e. statistical) tennis and snooker player rankings and ratings:
http://www.statsfair.com/