L'application iPhone SQLite prépare une déclaration d'erreur

Question

L'une des applications que je développe utilise SQLite pour stocker les données téléchargées à partir d'un serveur. L'application elle-même utilise le multi-threading afin que l'application se lance, l'application télécharge les données en arrière-plan tout en présentant également l'interface utilisateur à l'utilisateur.

L'utilisateur à ce moment peut commencer à naviguer dans l'application, en tapant sur les lignes du tableau pour explorer les pages détaillées. Parfois, lorsque j'appuie sur une ligne de table, l'application se bloque à l'un des nombreux appels de fonction sqlite3_prepare_v2(). Cela est arrivé beaucoup plus souvent lorsque j'autorise plus d'une opération simultanée maximale pour mon NSOperationQueue. Lorsque mon application est lancée, j'ouvre une connexion à une base de données et je la garde ouverte jusqu'à ce que l'application ait besoin de se terminer, puis Je ferme la connexion.

Voici une ligne d'exemple, il se bloque à:

if(sqlite3_prepare_v2(objDatabase, [strGet cStringUsingEncoding:NSUTF8StringEncoding], -1, &stmtGet, NULL) == SQLITE_OK) 
{ 
    ... 
} 

erreur indique EXEC_BAD_ACCESS

Comme 1 sur 20 ou 1 sur 30 pistes app, il se briserait. Cela signifie que mon instruction SQL fonctionne 99% du temps.

Quelqu'un a déjà eu cela avant?

Answer 1

Activer les objets zombies et vérifier s'il y a un problème dû à l'objet libéré car la plupart du temps, un mauvais accès est dû à des objets libérés. et en activant zombie, on vous dira pourquoi l'application s'est écrasée. cela peut être votre gestion de la mémoire n'est pas correctement que dans les différents threads, parfois votre méthode de gestion invoquer correctement quelques fois pas.

permettent des objets zombie ns de

produit> systèmes d'édition> permettent zombie et essayer de faire tomber l'app

Answer 2

J'ai eu ce même problème. Passez soigneusement en revue tous les appels aux instructions sqlite3_prepare_v2 et assurez-vous que la correspondance sqlite3_finalize est appelée pour chacun d'entre eux. Dans mon cas, j'avais un emplacement où sqlite3_finalize n'était pas appelé, causant le plantage la prochaine fois que sqlite3_prepare_v2 était appelé. Il ne plante pas toujours, et il est difficile de déboguer comme un fou. J'espère que ce commentaire pourrait vous aider.

Vous pourriez vraiment trouver utile d'écrire des fonctions de remplacement pour sqlite3_prepare_v2 et sqlite3_finalize qui consignent ces actions dans NSLog. Cela aidera à vérifier les appels correspondants.