I have a block of code in my iOS app that fills an array with Core Data objects on a background thread, via NSOperationQueue, then notifies the UI on the main thread when it completes.
Everything has worked perfectly in iOS3. However, in my new iOS4 build, I started noticing an occasional bug where the UI never gets notified that the data is ready. After investigation, I found that this was occurring because the background thread was exiting before the end of its code block. Specifically, it exits when hitting a line to execute a fetch request. I don't get any errors or exceptions when this happens, and the app still runs perfectly otherwise (other UI elements are responsive). I only figured this out by observing threadWillExit notifications. Also, this only happens on the device, not on the simulator.
I'm really not the most knowledgable person when it comes to multi-threading...Could someone give me some reasons for why the thread would exit itself prematurely without throwing any errors?
EDIT: Well I still don't understand why the thread dies, but I did solve the bug! Basically, in the background thread I had a few classes fetching data synchronously via executeFetchRequest. One of these fetches used a predicate based on a dynamically generated property (i.e., the accessor is overridden so it returns a calculated result instead of a stored result). I modified this fetch so that it didn't have to use that predicate anymore and I stopped having the problem.