[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNUstep and valgrind
From: |
Richard Frith-Macdonald |
Subject: |
Re: GNUstep and valgrind |
Date: |
Fri, 16 Mar 2018 17:21:12 +0000 |
> On 16 Mar 2018, at 16:53, Richard Frith-Macdonald
> <richard.frith-macdonald@theengagehub.com> wrote:
>
>
>
>> On 16 Mar 2018, at 15:44, Fred Kiefer <fredkiefer@gmx.de> wrote:
>>
>>
>>
>>> Am 16.03.2018 um 16:32 schrieb Richard Frith-Macdonald
>>> <richard.frith-macdonald@theengagehub.com>:
>>>
>>>
>>>
>>>> On 16 Mar 2018, at 15:18, amon <amon@vnl.com> wrote:
>>>>
>>>>
>>>> [arglist release];
>>>> arglist = [[[NSMutableString stringWithCString: [cmdline cString]]
>>>> componentsSeparatedByString: DELIM] retain];
>>>>
>>>> This happens inside an init. arglist is release by the dealloc
>>>> method. However, NSMutableString insists on making it autoreleased.
>>>> I want to make it not do that.
>>>
>>> Portable GNUstep code would look like this:
>>>
>>> CREATE_AUTORELEASE_POOL(pool);
>>> ASSIGN(arglist, [[[NSMutableString stringWithCString: [cmdline cString]]
>>> componentsSeparatedByString: DELIM]);
>>> DESTROY(pool);
>>>
>>> with no wasted/leaked memory.
>>
>> I have to disagree. This will get rid of the intermediate NSMutableString
>> but later on when the surrounding Foo object gets released the arglist ivar
>> will get released as well, but the component strings in that array will
>> still remain in what ever autorelease pool is active at that time and will
>> only get freed when that pool is cleaned up.
>
> That's (almost always) wrong. Releasing a container does not put its
> contents into an autorelease pool, it releases them all. so the components
> get released/deallocated at the point when the array is deallocated.
>
> Of course you can never guarantee that a class will behave normally (if you
> don't have access to its source code), but generally when an object is
> deallocated it releases all its instance variables.
>
> In this instance I think it's fair to assume we are talking about the GNUstep
> NSMutableString class generating components in a GNUstep NSArray, so we know
> that we don't have some perverse implementation and the above three-line
> solution is all that's needed to ensure no leaked objects.
>
> However, I agree that if someone had for instance re-implemented
> -componentsSeparatedByString: in a category of NSMutableString, and their
> re-implementation had created an NSArray subclass which, on deallocation,
> would put the array contents into an autorelease pool rather than releasing
> them, then you could get the situation you describe where the components
> would be placed in a pool at the point when the array ivar is released.
Of course your example:
// zone used = n bytes
CREATE_AUTORELEASE_POOL(pool);
obj = [Foo new];
// zone used = n+m bytes
[obj release];
DESTROY(pool);
// zone used = n bytes.
is perfect if what you care about the end result after finishing with the
instance of Foo.
The other:
CREATE_AUTORELEASE_POOL(pool);
ASSIGN(arglist, [[[NSMutableString stringWithCString: [cmdline cString]]
componentsSeparatedByString: DELIM]);
DESTROY(pool);
is what you'd do in a setter method of Foo, where the instance of Foo is
long-lived and you want to ensure that you don't increase memory usage duriung
that long life.
- Re: GNUstep and valgrind, (continued)
- Re: GNUstep and valgrind, Richard Frith-Macdonald, 2018/03/14
- Re: GNUstep and valgrind, amon, 2018/03/13
- Re: GNUstep and valgrind, amon, 2018/03/14
- Re: GNUstep and valgrind, amon, 2018/03/16
- Re: GNUstep and valgrind, Richard Frith-Macdonald, 2018/03/16
- Re: GNUstep and valgrind, Fred Kiefer, 2018/03/16
- Re: GNUstep and valgrind, Richard Frith-Macdonald, 2018/03/16
- Re: GNUstep and valgrind,
Richard Frith-Macdonald <=
- Re: GNUstep and valgrind, Fred Kiefer, 2018/03/16
- Re: GNUstep and valgrind, Fred Kiefer, 2018/03/16
- Re: GNUstep and valgrind, Richard Frith-Macdonald, 2018/03/16
- Re: GNUstep and valgrind, amon, 2018/03/16
- Re: GNUstep and valgrind, amon, 2018/03/17
- Re: GNUstep and valgrind, Ivan Vučica, 2018/03/17
- Re: GNUstep and valgrind, amon, 2018/03/17
- Re: GNUstep and valgrind, Fred Kiefer, 2018/03/18
- Re: GNUstep and valgrind, Richard Frith-Macdonald, 2018/03/18
- Re: GNUstep and valgrind, amon, 2018/03/19