discuss-gnustep
[Top][All Lists]
Advanced

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

Re: GNUstep and valgrind


From: H. Nikolaus Schaller
Subject: Re: GNUstep and valgrind
Date: Tue, 20 Mar 2018 08:22:54 +0100

> Am 20.03.2018 um 08:11 schrieb Andreas Fink <afink@list.fink.org>:
> 
> 
> You never call "release" on a autorelease pool.

Not "never": 
https://developer.apple.com/documentation/foundation/nsautoreleasepool

Using drain over release is a "should" not a "must".

> you call "drain" to empty it.
> 
> 
>       NSAutoreleasePool  *arp=[[NSAutoreleasePool alloc]init];
> ...
>       [arp drain];

> 
> 
> would be more or less the same as
> 
> @autoreleasepool {
> ...
> }
> 
> 
> 
>> On 20 Mar 2018, at 08:08, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>> 
>> 
>>> Am 20.03.2018 um 07:31 schrieb amon <amon@vnl.com>:
>>> 
>>> 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.
>> 
>> Well, there may be this pattern:
>> 
>> while(YES) {
>>      arp=[NSAutoreleasePool new];
>>      object = do something
>>      var=[object retain]
>>      [arp release]
>> }
>> 
>> Then, the object will leak despite using an ARP and releasing it.
>> The issue is that var=[object retain] will *not* release the previous
>> var. That is what the ASSIGN macro would be good for.
>> 
>> Unfortunately I also don't have a clear method to track down such
>> issues especially if they are distributed over multiple frameworks.
>> 
>>> 
>>> If nothing else, I am getting a much better handle on how and
>>> when memory gets sucked up.
>>> 
>>> 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)
>> 
>> this is the Singleton Pattern: 
>> https://en.wikipedia.org/wiki/Singleton_pattern
>> 
>>> 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?
>> 
>> You can find out by running
>> 
>>      NSLog(@"%p", [NSHost hostWithAddress:@"10.0.0.1"]);
>> 
>> twice in succession.
>> 
>> 
>> _______________________________________________
>> Discuss-gnustep mailing list
>> Discuss-gnustep@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
> 
> 




reply via email to

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