2017-10-07 8 views
0

J'ai un problème étrange après beaucoup de recherche et de lecture, je n'ai toujours aucune idée de ce qui provoque la faute seg ici. S'il vous plaît considérer le code C++ suivant:Erreur chaîne C/C++ avec erreur de segment ARM Erreur de bus

void SensorCalibrator::getCoordinatesFromSensorMac(string in_mac, double *in_coor3D) { 
    map<string, sensorInformation>::iterator itr = mac_to_sensorinfo.find(in_mac); 
    if(itr != mac_to_sensorinfo.end()) { 
     in_coor3D[0] = itr->second.coor[0]; 
     in_coor3D[1] = itr->second.coor[1]; 
     in_coor3D[2] = itr->second.coor[2]; 
    } 
    else { 
       in_coor3D[0] = 50.0; 
       in_coor3D[1] = 55.0; 
       in_coor3D[3] = 2.45; 

    } 
} 

Le double tableau in_coor3D est initialisé avant qu'il ne soit transmis à la méthode getCoordinatesFromSensorMac donc pas de soucis là-bas. Ce code n'a aucun problème sur une architecture Intel ou AMD 64 Bit mais sur un ARM v7l (Raspberry Pi 3) il se bloque avec un "Segmentation Fault" (g ++ v5) ou un "Bus Error" (g ++ v4.7). Voici le backtrace GDB correspondant:

Program received signal SIGSEGV, Segmentation fault. 
__GI___libc_free (mem=0x9999999a) at malloc.c:2966 
2966 malloc.c: No such file or directory. 
(gdb) bt 
0 __GI___libc_free (mem=0x9999999a) at malloc.c:2966 
1 0x7679fb90 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()() from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 
2 0x00053b64 in WiPiDevicesHandler::setSensorCoordinates (this=0xf24e0, sens=0x110458) at ../WiPiDevicesHandler.cc:437 

La ligne 437 est l'appel à la méthode getCoordinatesFromSensorMac. Je réinsérait débogage printf dans la méthode et il semble que la chaîne in_mac est à l'origine du problème, et voici ce que j'ai trouvé à ce jour:

  1. La chaîne in_mac est bien avant que la méthode est appelée et à l'intérieur de la méthode.

  2. si in_mac est trouvé dans le std:map (à l'intérieur du si) alors la méthode ne plante pas.

  3. si in_mac ne se trouve pas dans la std:map (à l'intérieur du reste), la chaîne in_mac a disparu, ce qui signifie que un printf avec in_mac accidents. GDB dit aussi "ne peut pas accéder à la mémoire à 0x99999a" pour la chaîne.

Comme je l'ai mentionné, la même méthode n'a aucun problème sur une architecture AMD 64Bit. Ma conjecture est que sur la chaîne ARM Architecture est déplacée vers une adresse qui est considérée comme "libérée" et l'accident se produit et aussi je soupçonne que cela vient de la fonction std:map find. Au-delà, je n'ai aucune idée de ce qui cause ce crash. As tu des idées ? Thx.

Répondre

1

Le problème est la faute de frappe:

in_coor3D[3] = 2.45; 

il devrait très probablement:

in_coor3D[2] = 2.45; 
+0

homme Oh, c'est vraiment très embarrassant. Merci beaucoup. – Jonas