>> On Sep 1, 2015, at 9:37 AM, Roger Binns <rogerb at rogerbinns.com> wrote:
>>
>> On 08/31/2015 11:28 PM, Jeff M wrote:
>> All my bad -- I'm fessing up.
>
> Can you tell us how you found the root causes of the problems? It
> would be nice to know what tools and techniques worked.
> Roger
Since you asked...
The crash investigation: Many of the stack traces showed the ESC_BAD_ACCESS
was at a harmless looking objectForKey: call, so I added a dozen more
objectForKey: calls at the same place on the main thread to make it crash more
often, then I moved the setObject:forKey: back and forth between the background
thread and the main thread. It almost always crashed when on the background
thread, but never crashed when on the main thread. I searched
stackoverflow.com for things like "objectForKey: crash" and found several
threads describing my situation. The answers quoted Apple docs saying that
NSMutableDictionary was not thread safe, and I should have known that.
Stackoverflow.com is a terrific resource. [Xcode's stack trace was misleading
because it often appeared that the crash was in sqlite3_step(), and that led to
my initial post here.]
For the memory allocation issue, I used Instruments to list the objects and
mallocs that were unbalanced ("persistent"), and most of them were mallocs in
SQLite. I knew that SQLite would *not* have a bug like this, thus it had to be
my mistake (I was only in denial for few hours :-), so I just kept picking at
my code. The problem went away when I finalized each prepared statement
immediately after the existing reset (a trivial change). That led me to places
where I was mishandling a pointer to a prepared statement pointer (so it was a
pointer to a pointer, but my prepare code was treating it as only a pointer),
causing several statements to be prepared dozens of times, while finalizing
none of them. Just a case of clever code hiding something sinister.
Jeff
