25,962 frames on the stack seems to me rather a lot. Yes unarchiving is a very
recursive process but that seems pretty deep.
I missed the start of this thread so I don't know what mechanism you are using
to archive and unarchive things, but is it possible you've tripped it up and
it's going around a loop in the object graph and creating the same things over
and over again (I know the standard archiver/unarchiver classes are coded to
avoid that but if you have some code of your own, or have found a bug in them
.. ). I think the best advice there was to look at the allocations screen on
instruments, sort it by number of objects, it should be very clear very quickly
if you expect to have made a few hundred of something whilst unarchiving and
you have 20,000 of them.
You could take a look at the stack trace as well, see if it looks like it's
repeating itself, if it does and goes through any of your code then that gives
you a place to look.
On May 10, 2012, at 8:40 AM, James Maxwell wrote:
> 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 (Cocoa-dev@lists.apple.com)
>
> 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/rols%40rols.org
>
> This email sent to r...@rols.org
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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 arch...@mail-archive.com
