[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Running app with ARC turned off
From: |
Andreas Fink |
Subject: |
Re: Running app with ARC turned off |
Date: |
Tue, 10 Dec 2024 14:59:05 +0100 |
If you run gnustep code, you must have an autorelease pool setup and drain it
from time to time to get rid of autorelease objects. If you dont do that, you
will accumulate a lot of garbage in the pool which never gets released.
this is especially true if you start your own threads. Even if your code uses
ARC, you will call into gnustep code (non ARC) which might use temporary
variables as return values which end up in the autorelease pool at some point
and you never drain it, its just waiting to eat up all your memory.
> On 10 Dec 2024, at 14:55, Daniel Santos <daniel.dlds@gmail.com> wrote:
>
> I have some test classes that run the code (the main code is a library) and
> if I don’t create an AutoReleasePool object I get warnings like :
>
> autorelease called without pool for object of class … (for example
> GSMutableDictionary)
>
> Does that mean that it is my responsibility to release the object right ? But
> most of the objects in the warnings belong to GNUstep base (which I am using)
>
> Daniel Santos
>
>
>
>> On 10 Dec 2024, at 13:09, Andreas Fink <afink@list.fink.org> wrote:
>>
>> but that depends on how you compile your code as you can have bits of code
>> compiled with ARC together with pieces of code which are not using ARC.
>> As far as I remember, the code of gnustep itself doesn't use ARC (otherwise
>> it would not be backwards compatible with systems not supporting ARC yet)
>> and you can mix and match code freely as its just the compiler inserting the
>> necessary code on the fly
>>
>>
>>> On 10 Dec 2024, at 14:01, Daniel Santos <daniel.dlds@gmail.com> wrote:
>>>
>>> I agree, but my objective is to have ARC disabled to try to reproduce the
>>> memory allocations that happen in NeXT (that does not have ARC).
>>> Meaning that with ARC disabled I will have to explicitly release objects
>>> and therefore catching memory allocation bugs that will happen on the
>>> NeXTStep version of the code.
>>>
>>> Daniel Santos
>>>
>>>
>>>
>>>> On 10 Dec 2024, at 11:29, Andreas Fink <afink@list.fink.org> wrote:
>>>>
>>>> valgrind should have no issue with ARC at all. In fact it results in
>>>> objects being released instantly instead of sometimes later so memory
>>>> issues might show up quicker.
>>>> But as valgrind traces malloc/free calls (or some variants of them) which
>>>> ARC ultimately use at some point, using ARC or not should not have any
>>>> effect.
>>>>
>>>>> On 10 Dec 2024, at 12:07, Daniel Santos <daniel.dlds@gmail.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I am developing an application that runs both in NeXTStep and on Linux
>>>>> with GNUStep.
>>>>> As far as I know GNUStep uses Auto release pools to manage memory and
>>>>> Automatic Reference Counting.
>>>>>
>>>>> I want to run the app under valgrind on Linux with ARC turned off because
>>>>> debugging memory leaks with NeXTStep tool (malloc debug I think that’s
>>>>> what is called) is much harder and the tool is not as good as valgrind.
>>>>>
>>>>> Is it possible to turn off ARC in GNUstep ?
>>>>>
>>>>> Thanks,
>>>>> Regards
>>>>> Daniel Santos
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>