[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
>
>
- Re: GNUstep and valgrind, (continued)
- Re: GNUstep and valgrind, amon, 2018/03/19
- Re: GNUstep and valgrind, Fred Kiefer, 2018/03/19
- Re: GNUstep and valgrind, Richard Frith-Macdonald, 2018/03/19
- Re: GNUstep and valgrind, amon, 2018/03/20
- Re: GNUstep and valgrind, amon, 2018/03/20
- Re: GNUstep and valgrind, H. Nikolaus Schaller, 2018/03/20
- Re: GNUstep and valgrind, Andreas Fink, 2018/03/20
- Re: GNUstep and valgrind,
H. Nikolaus Schaller <=
- Re: GNUstep and valgrind, Andreas Fink, 2018/03/20
- Re: GNUstep and valgrind, H. Nikolaus Schaller, 2018/03/20
- Re: GNUstep and valgrind, Andreas Fink, 2018/03/20
- Re: GNUstep and valgrind, David Chisnall, 2018/03/20
- Re: GNUstep and valgrind, Wolfgang Lux, 2018/03/20
- Re: GNUstep and valgrind, David Chisnall, 2018/03/20
- Re: GNUstep and valgrind, Richard Frith-Macdonald, 2018/03/20
- Re: GNUstep and valgrind, Richard Frith-Macdonald, 2018/03/20
- Re: GNUstep and valgrind, amon, 2018/03/20
- Re: GNUstep and valgrind, Riccardo Mottola, 2018/03/20