Fatal signal 11 (SIGSEGV)

J'ai une erreur bizarre et je ne trouve pas d'où il vient. La seule chose qui apparaît dans le logcat :

01-10 17:07:10.665: A/libc(20449): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1)

Je n'ai pas cette erreur tout de suite quand je lance mon application, je l'obtenir après un certain temps (entre 1 min à 5 min). Je ne suis pas en mesure de reproduire cette erreur, il semble aléatoire et depuis il n'y a pas d'autres informations qu'il est difficile à déboguer. J'ai essayé d'ajouter un peu de journal d'informations de ma bibliothèque, mais je ne peux pas encore dire où l'incident se produit.

J'ai couru à la même application x fois et j'ai eu différents SIGSEGV adresse (parfois, il était à la même adresse qu'avant :

01-10 17:29:04.650: A/libc(21588): Fatal signal 11 (SIGSEGV) at 0x6c707063 (code=1)

01-10 17:25:55.165: A/libc(21473): Fatal signal 11 (SIGSEGV) at 0x0069004c (code=1)

01-10 17:11:58.780: A/libc(20742): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1)

01-10 17:00:02.010: A/libc(20160): Fatal signal 11 (SIGSEGV) at 0x00000018 (code=1)

Mon application est à l'aide d'une bibliothèque c++ qui a un NetworkThread qui reçoit des mises à jour à partir d'un serveur. Sur le Java côté il y a un WorkerThread que l'enregistrement est qu'il y a de nouvelles mises à jour à partir de la NetworkThread et si il y a de nouvelles mises à jour, il notifie à tous les auditeurs. J'ai aussi un LocationSpotter (sur le Java côté) qui fait que certaines JNI des appels lorsque l'emplacement est mis à jour.

Est-il un moyen de débogage ou d'utiliser les adresses que j'ai eu de la SIGSEGV pour déboguer l'application ? Je suis aussi partagé un JavaVM objet pour certaines méthodes pour récupérer le courant JNIEnv (et appel AttachCurrentThread). C'est que "thread-safe"?

J'ai remarqué que je continue de recevoir des mises à jour à partir de la NetworkThread après j'ai eu la SIGSEGV erreur (avant l'application fait des plantages). Cela signifie que le NetworkThread est probablement de travail.

J'ai aussi remarqué une ligne qui pourrait être la source de mon problème (dans la méthode notifyAll) parce que le dernier message imprimé avant SIGSEGV est "notifyAll1" :

for (unsigned i = 0; i < listeners.size(); i++) {
    try {
        __android_log_print(ANDROID_LOG_INFO, "FROM C++", "notifyAll1");
        if (listeners.at(i) == NULL)
            __android_log_print(ANDROID_LOG_INFO, "FROM C++", "LISTENER NULL");


        listeners.at(i)->update(u); //<- This line is a potential suspect
        __android_log_print(ANDROID_LOG_INFO, "FROM C++", "notifyAll2");

Le logcat :

01-10 17:07:10.665: I/FROM C++(20449): notifyAll1
01-10 17:07:10.665: A/libc(20449): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1)

J'ai essayé alors d'imprimer un journal, à la première ligne de chaque auditeur update méthode, mais aucun d'eux n'est imprimé (ce qui est vraiment bizarre, je pense).

Toute aide sera grandement appréciée

Vous pouvez ajouter la pierre tombale de fichier de données //pierres tombales dir si l'un est créé après votre accident?
Je ne pouvais pas trouver une pierre tombale de fichier. J'ai essayé d'aller sous la perspective DDMS -> Explorateur de Fichier -> données> données> (Paquet) -> fichiers -> (Votre Fichier), mais il n'y avait rien... j'ai essayé que sur le téléphone, mais pas plus de résultats
Par la voie savez-vous pourquoi il n'y a rien dans le répertoire de données sur mon téléphone ? Dois-je root mon téléphone pour être en mesure de lire la pierre tombale de fichiers ? (stackoverflow.com/a/8921133/1304830)
Fondamentalement, vous êtes déréférencement d'un pointeur non valide, probablement dans votre code par la remise d'un système de bibliothèque de code, ou beaucoup moins susceptibles de déclencher une plate-forme de bug. La principale chose que vous voulez trouver est un natif de vidage de pile de l'accident, à tout hasard, c'était déjà dans votre logcat?. Le haut niveau de répertoire de données n'est pas accessible sur une garantie de l'appareil, mais vous pouvez être en mesure de cd-rom dans un répertoire spécifique en dessous de la commande adb shell. Ou vous pouvez être en mesure de reproduire le problème sur un émulateur, où la commande adb shell est déjà de la racine.
Comment avez-vous activer les exceptions dans votre code natif? Qui STL utilisez-vous?

OriginalL'auteur Fr4nz | 2013-01-10

3

La plupart du temps Mortelle signal d'erreur se produire lorsque vous essayez d'accéder à un objet qui n'est pas créé à l'époque. Afin de vérifier correctement.

OriginalL'auteur Singhak
1

Je pense que vous devez réécrire le notifyAll boucle comme ceci:
```
for (unsigned i = 0; i < listeners.size(); i++) {
  try {
    __android_log_print(ANDROID_LOG_INFO, "FROM C++", "notifyAll1 i=%u", i);
    auto listener = *listeners.at(i);

    if (&listener == NULL) {
      __android_log_print(ANDROID_LOG_INFO, "FROM C++", "LISTENER NULL");
    }
    else {
      __android_log_print(ANDROID_LOG_INFO, "FROM C++", "notifyAll2 : listener[%u] at %p", i, &listener);
      listener.update(u);
    }
```
- dans votre code d'origine, le chèque a été seulement de l'impression de journaux, mais mise à jour() serait toujours pas (@Robin remarqué ce)
- dans votre code original, un auditeur pourrait invalidé NULL entre les vérifier et mise à jour()
- même après le changement ci-dessus, mise à jour() peut se bloquer si l'auditeur objet pointé par auditeurs.(i) devient invalide.
Mais il est possible que l'accident se produit en raison de la gestion des exceptions. Vous n'avez pas de révéler la catch(...) code, donc je ne peux pas en parler.

OriginalL'auteur Alex Cohn

Il semble évident

if (listeners.at(i) == NULL)
            __android_log_print(ANDROID_LOG_INFO, "FROM C++", "LISTENER NULL");


        listeners.at(i)->update(u); //<- This line is a potential suspect
        __android_log_print(ANDROID_LOG_INFO, "FROM C++", "notifyAll2");

devrait être

if (listeners.at(i) == NULL) {
    __android_log_print(ANDROID_LOG_INFO, "FROM C++", "LISTENER NULL");
} else {
    listeners.at(i)->update(u); //<- This line is a potential suspect
    __android_log_print(ANDROID_LOG_INFO, "FROM C++", "notifyAll2");
}

OriginalL'auteur Robin

Vous devez vous connecter pour publier un commentaire.