[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUstep, Valgring and Memory leaks.

From: Richard Frith-Macdonald
Subject: Re: GNUstep, Valgring and Memory leaks.
Date: Tue, 31 Aug 2004 11:47:22 +0100

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]