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
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,
On May 1, 2010, at 5:04 PM, James Maxwell jbmaxw...@rubato-music.com
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
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
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
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
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)
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 -- something is
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 arbitrarily,
On Sun, May 2, 2010 at 1:50 AM, James Maxwell
jbmaxw...@rubato-music.com 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
10 matches
Mail list logo
