Re: crashes loading saved file
Re: crashes loading saved file
- Subject: Re: crashes loading saved file
- From: James Maxwell <email@hidden>
- Date: Fri, 11 May 2012 12:21:28 -0700
Yes, I agree about 25k frames being pretty big. It's possible though, because the structure being unarchived is pretty complex... I decided to put an NSLog(@"Unarchiving %p", self) at the line where the crash finally occurs in initWithCoder of my CbCMNode class. Pasting the output into TextWrangler and searching for any given object returns only a single match, so I'm guessing there's no actual looping going on (but maybe there's a better way to check?). Interestingly, I just ran the Allocations instrument and it opened the file just fine. Poking a little more I noticed that profiling was running the release build, which is on -O2 optimization, and seems to be able to load... Of course, this will probably break as well, if I do more training.
Unfortunately, ARC is going to be awkward with this project, as I'm getting loads of complaints from the ARC migration macro (not so many in my own code, but a few from DrawKit, which is used heavily in my app). But, either way, I think I have to figure out how to get the memory down. What seems strange to me is that, once the app is open, it's only taking 50 MB in real memory -- less than Mail, the Finder, Safari... So it's not a huge amount of memory. I think it's just the fact that the stack gets filled **during** the unarchiving process. But surely there must be a way around this. No?
J.
On 2012-05-09, at 7:11 PM, Roland King wrote:
> 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 (email@hidden)
>>
>> 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:
>>
>> This email sent to email@hidden
>
------------------------------------------------------
James B. Maxwell
Composer/Researcher/PhD Candidate
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden