Re: GNUstep and valgrind

[Richard Frith-Macdonald]

> On 20 Mar 2018, at 06:31, amon <amon@vnl.com> wrote:
> 
> Richard:
> 
> Thanks. I will look at that.
> 
> And btw, to the person who suggested @autorelease... I was
> certain it would not compile, but I tried it anyway. Needless
> to say, it did not compile.
> 
> I did try coding
> p=[NSAutoreleasePool new]; do something; [p release];
> and in some cases it seemed to help. In others it did not.
> I'll be digging deeper tomorrow and I will give the macros
> you suggested a try.

The macros are just a wrapper round the code you used, intended to make it 
easier to port to using garbage collection (no longer supported) or ARC.
So 'p=[NSAutoreleasePool new]; do something; [p release];' is fine.
Where it "doesn't help" you will be experiencing cases of 
caching/lazy-initialisation.  These are features designed to improve program 
performance and you should generally not worry about them.
That is to say, before worrying about the internals of the library code (which 
is certainly largely leak free), you need to debug your own code and ensure 
it's not leaking things itself.

Typically, if you have an event driver program the NSRunLoop implementation 
will create an autorelease pool before calling your event handler, and release 
that pool after calling your event handler.  This means that, unless you create 
vast quantities of autoreleased objects (enough to crash your program) handling 
a single event, you should not be worrying about autorelease!
If you aren't handling events within a callback from NSRunLoop and are using 
some other mechanism of your own, you should do the same thing ... create a 
pool before handlign each event and release it after handling the event.
NB . ignore the release/drain debate ... both methods do the same thing in your 
environment.

Your most likely cause of a problem (assuming handling each event is wrappen in 
pool create/release) is a retain/release error in your own code.  To avoid that 
it's safest not to use retain/release and always use methods that return 
autoreleased objects.
If you are writing classes, the two biggest areas for mistakes are
a. assignment to instance variables (to minimise errors, use the ASSIGN macro 
to assign an autorelease value to a variable)
b. object deallocation ... make sure that the -dealloc method releases all its 
instance variables (use the DESTROY macro to help

You can call the GSDebugAllocationList() function (one of many diagnostic 
features in NSDebug.h) before and after handling an event, to see what objects 
have been created/destroyed and spot leaks.

> If nothing else, I am getting a much better handle on how and
> when memory gets sucked up.

That's good knowledge to have.  Most likely long term leaks are not in the 
library (though, since you are using a very old version there's more of a 
chance of it), but you might find one, and more likely you might find a case 
where some feature caches more data than you are happy with (if your available 
memory is very tight) and you might want to investigate options to overcome 
that. 

> A question on NSHost then. If NSHost essentially returns a
> cache of something like what NeXT used to call Class Objects,
> like the old Printer Class that always returned the same
> object (A technique I still use for something btw) then that
> would be less troubling. But to be clear, If I create an NSHost
> for "10.0.0.1" in one place in the code, and then some entirely
> other area creates one with the same IP, I presume you are
> seeing that it will return a pointer to the same object? That
> there will never be two NSHosts with the same IP?

Correct (unless the cache is flushed ... in which case new objects after the 
flush will differ from old ones).