Thanks All,
I'm just using retain-release, so I'll look into converting a version to ARC.
Unfortunately, I can't go 64-bit as I'm using DrawKit heavily, which doesn't
seem to support 64-bit builds. I'll also look into @autoreleasepool in certain
places. I do have a tendency to use the factory methods from NSNumber quite
often, so there may be cases where I'm creating lots of autoreleased NSNumber
objects.
However, I have to admit that I'm not sure how to fix the unarchiving process,
since the code runs fine while all the learning is happening and the graph is
being built. It seems to be the unarchiving process in particular that's a
problem. Is there some other way of periodically draining the pool during the
unarchiving process?
J.
On 2012-05-09, at 12:55 PM, Fritz Anderson wrote:
> On 9 May 2012, at 1:58 PM, James Maxwell wrote:
>
>> This morning, I tried enabling Guard Malloc (on its own, without zombies),
>> and was surprised to see the app crash during training, with the following
>> error:
>>
>> GuardMalloc[ManuScore-2438]: Failed to VM allocate 1864016 bytes
>> GuardMalloc[ManuScore-2438]: Explicitly trapping into debugger!!!
>>
>>
>> Is it simply running out of VM while trying to build the graph? If so, why
>> doesn't this happen with Guard Malloc off? Also, with zombies and guard
>> malloc off, why is it only when reading the file that the app crashes, not
>> during training (i.e., while the graph is being built)?
>>
>> One thing I have noticed, that seems pretty weird, is that the complete
>> backtrace when it crashes during unarchiving is 25962 frames long! Could it
>> simply be that it's running out of memory while trying to unarchive (i.e.,
>> on the stack)? If so, how can I get around that? Some sort of caching,
>> perhaps?
>> The file is only 9.6 MB, so it's not a massive file...
>
> 1. What kind of memory-management scheme are you using? Garbage collection,
> ARC, or retain-release?
>
> 2. Assuming (praying) that you're on a version-control system, consider
> creating a branch and converting the project to ARC. It will make better
> memory-management choices than you will. See if that helps.
>
> 3. Are you accumulating lots of temporary (autoreleased) objects? Can you
> investigate embedding code inside loops in @autoreleasepool{...} blocks?
> @autoreleasepool is not an ARC feature. It's usable in any OS target, and ARC
> / ARC conversion don't create local autorelease pools for you.
>
> 4. What does the Allocations template in Instruments tell you?
>
> 5. Failing all of that, would you be comfortable posting your -initWithCoder:
> methods?
>
> — F
>
>
> --
> Fritz Anderson -- Xcode 4 Unleashed: Due 21 May 2012 --
> <http://x4u.manoverboard.org/>
>
------------------------------------------------------
James B. Maxwell
Composer/Researcher/PhD Candidate
_______________________________________________
Cocoa-dev mailing list ([email protected])
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
