Simon, Roger: I've checked all of your suggestions and nothing is amiss.
The background thread fetches the image data and caches it by adding the data to an NSMutableDictionary. The main thread checks the dictionary and does the lazy-load only if the desired image data is not in the cache. When the exception occurs on the main thread, execution stops where the dictionary is being checked (via objectForKey:), and the lazy-load background thread is executing inside of sqlite_step (sqlite_step has not returned when the exception occurs on the main thread). This perplexes me. I don't understand how the main thread can run before the background task has completed -- and specifically while sqlite_step is still executing. Apparently, sqlite_step() can relinquish control to the main thread. I'd appreciate some enlightenment on this implementation issue. My solution -- The problem goes away if I move the caching step (setObject:forKey:) to the main thread (via dispatch_async(dispatch_get_main_queue() ). It was intermittent so I can't be certain, but I've not been able to force a crash since making that change. Jeff > On Aug 23, 2015, at 7:05 AM, Simon Slavin <slavins at bigfraud.org> wrote: > > Are you checking the values returned by sqlite3_prepare, sqlite3_bind, and > sqlite3_step, to make sure they return SQLITE_OK ? > On Aug 23, 2015, at 7:00 PM, Roger Binns <rogerb at rogerbinns.com> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 08/23/2015 03:31 AM, Jeff M wrote: >> sqlite3_step(); // occasionally crashes here (showing >> ESC_BAD_ACCESS on main thread) > > That has three very likely causes. The first is that your internal > state gets messed up, and the statement has actually been > finalized/freed. ie it is junk memory. You can add assertions that > check it is still a known statement pointer by checking this returns it: > > http://sqlite.org/c3ref/next_stmt.html > > The second is that the memory where you stored the statement pointer > is what is trashed. > > The final cause is that some other code has memory bugs, causing > damage to SQLite's data structures. > >> It's not a zombie object issue (tested with NSZombieEnabled). > > Sadly that only checks Objective C objects, and not all memory. > >> Any ideas on how to debug this? > > I used valgrind running the app in the simulator. (I also configure > valgrind to never actually reuse memory.) > > Roger > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iEYEARECAAYFAlXaXpEACgkQmOOfHg372QRKZACfWyT6pEyNQ9sEKPbhFQ4pI/5G > Nh0AniO5ESx9CIbB484/gYqjtfCsGUrM > =Op+8 > -----END PGP SIGNATURE----- > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
