Yes, this all makes sense to me. I'm not super advanced, but I do at least
understand the idea of keeping reads/writes temporally distinct.
Anyway, it looks like I found the problem. There was a somewhat unnecessary (or
at least easily avoidable call) happening to a method that **does** tamper w
On Sun, May 2, 2010 at 1:50 AM, James Maxwell
wrote:
>> On May 1, 2010, at 21:22, James Maxwell wrote:
>>
>>> If I drop into the debugger arbitrarily, before the crash, and check this
>>> same array, I noticed that it is nicely filled with NSCFNumbers. But,
>>> strangely, there are too many.
>>
>>
>
> This strongly suggests a memory management problem -- something is
> over-releasing the items in the array.
>
okay, this is what I figured, but I can't see anywhere where this could be
happening.
> On May 1, 2010, at 21:22, James Maxwell wrote:
>
>> If I drop into the debugger arbi
On May 1, 2010, at 20:42, James Maxwell wrote:
> So, looking more closely at the NSArray itself in the debugger, the items in
> the array come up as
>
> 0 NSCFNumber*
> 1 NSCFNumber*
> 2 NSObject*
> 3 _NSZombie_CFNumber*
> 4 NSObject*
This strongly suggests a memory management problem -- someth
Poking around some more...
If I drop into the debugger arbitrarily, before the crash, and check this same
array, I noticed that it is nicely filled with NSCFNumbers. But, strangely,
there are too many. The code that fills this array, is this:
- (void)
addCoincide
ugh... okay, so changing the logic cured the crashes, but also negatively
impacted the system (it's a machine-learning thing, and the old logic was
crucial to the predictive power of the system).
So, I'm back to the crash.
So, looking more closely at the NSArray itself in the debugger, the items
just to call off the dogs, in case there are any, I solved the crash by
re-working the logic a little.
It's cleaner the new way anyway, though I don't know whether the concurrency
stuff is really fixed
(or whether it was "really" broken!)
It works, and I'm a tight deadline, so that's all that m
Okay, so let me give a little more info.
Here's the stack trace.
#0 0x7fff8578693c in __CFTypeCollectionRelease
#1 0x7fff85783e43 in __CFArrayReleaseValues
#2 0x7fff85764bc8 in _CFArrayReplaceValues
#3 0x1000183ad in -[HSMM_Node addCoincidenceToBeliefMemory:] at
HSMM_Node.m:2
On May 1, 2010, at 5:04 PM, James Maxwell
wrote:
I'm having a crash when trying to remove the last item in an
NSMutableArray.
The app is a pretty complex system, and runs its two main processes
in consecutively executed blocks.
The blocks are run using dispatch_apply, on the global queue.
I'm having a crash when trying to remove the last item in an NSMutableArray.
The app is a pretty complex system, and runs its two main processes in
consecutively executed blocks.
The blocks are run using dispatch_apply, on the global queue. The operation
that's trying to
access the NSArray is, I
10 matches
Mail list logo
