Re: GNUstep, Valgring and Memory leaks.

[Richard Frith-Macdonald]

On 31 Aug 2004, at 10:50, Ronan Collobert wrote:

> However, one of my main concern is debugging facilities in 
> Objective-C. We
> used to employ valgrind (http://valgrind.kde.org/) a lot (in particular
> for leak problems detection).

GNUstep has quite a lot of debugging facilities built in ...  see 
NSDebug.h in
the base library for information about debugging object 
allocation/deallocation.

> Unfortunately, it seems that many small
> leaks occurs when using GNUstep (see in attachment the output of 
> valgrind,
> for the base example dictionary.m). Some leaks are related to the objc
> library, some to the ld library, and some to the GNUstep library.
>
> Many of these leaks are not really important (it is for example memory
> allocated in NSObject:initialize only once, or memory allocated for the
> locales in NSProcessInfo) but still, it becomes quickly annoying to 
> find
> our own memory problem with such an output.
>
> Also, it seems that valgrind is lost with the Objective-C object
> allocation: if we do not free an object, valgrind seems not to see the
> correct line in the code where the object was allocated.
>
> Are you guys using valgrind with GNUstep,

I can't speak for anyone else, but I don't use it.

> and if yes, how do you deal with
> memory leaks detection? Do you believe that the memory leaks mentioned
> above will be corrected in the near future?

As I'm not familiar with valgrind, I can't be sure about what the 
reports mean.
If bug reports for memory leaks which have a real impact are filed, 
they will
get fixed as a high priority, but my impression is that the log is 
identifying
situations I would not call leaks ... if memory is intentionally 
allocated for
the lifetime of the process and never explicitly freed, I wouldn't call 
it a leak.
As you mention, this is often the case in +initialize methods.
If there is a cheap, simple way to tell valgrind about these situations 
(or
a trivial way to alter the code to avoid worrying valgrind) I'd happily 
accept
patches to do it.

I know that there are also situations where there are intentional leaks 
...
ie. where memory is deliberately leaked because freeing it is difficult 
for
some reason, and the leak should not be a problem.  For instance,
libobjc (part of gcc rather than gnustep) does this when changing class
lookup tables ... so that it can avoid having to lock protect all code 
using
the tables in a multi-threaded environment.  The leaked version of the
table is there so that another thread which happens to be using the
table at the point when it is updated will be able to continue correctly
without crashing.  The only reason this is not utterly horrible is that
these tables are only rarely changed.  It would be better if this leak 
was
fixed, but it's not seen as high priority by the gcc maintainers.