Faire face à une erreur "*** glibc détecté *** gratuit(): invalide taille suivante (rapide)"

Question

Veuillez consulter la question MSO A long list of possible duplicates — C memory allocation and overrunning bounds pour obtenir des informations sur des questions connexes.

---

environnement de développement: CentOS 4.7, Kdevelop 3.1.1, gcc 3.4.6

je lance un client de test Java qui charge une bibliothèque C++ partagée en utilisant JNI. Il y a trois éléments dans ma demande,

1. client Java
2. C++ bibliothèque partagée qui agit comme une enveloppe JNI. (Je l'appellerai "wrapperlibrary")
3. Bibliothèque partagée C++ contenant des objets métier. (Je l'appellerai « businesslibrary »)

Quand je lance le client face à une erreur, je très fréquemment, ce qui est, *** glibc detected *** free(): invalid next size (fast): 0x080eeef8 ***. Cette erreur survient environ 10 à 11 fois, puis l'application s'exécute.

Dans mon client Java, je d'abord charger les bibliothèques C++ nécessaires dans un cteur statique comme suit,

static 
{ 
System.Load("/root/Desktop/libs/businesslibrary"); 
System.out.println("business library loaded"); 
System.Load("/root/Desktop/libs/wrapperlibrary"); 
System.out.println("wrapper library loaded"); 
} 

La déclaration « bibliothèque d'affaires chargée » est imprimé sur la console, mais après l'erreur *** glibc... vient.

Dans les paramètres du projet de la bibliothèque wrapper, la bibliothèque commerciale est spécifiée en tant que bibliothèque dépendante. Donc, même si je laisse de côté l'appel à charger businesslibrary et il suffit d'écrire,

static 
{ 
System.Load("/root/Desktop/libs/wrapperlibrary"); 
System.out.println("wrapper library loaded"); 
} 

puis tout d'abord le businesslibrary obtient chargé (vu par l'exploitation forestière de création variable globale), puis le wrapperlibrary être chargée. Le contrôle revient au client java et l'instruction "bandothèque chargée" est imprimée sur la console. Après cela, il y a un appel à la méthode native. Mais le contrôle n'atteint jamais l'implémentation de cette méthode native. Plutôt avant que l'erreur *** glibc... vient à nouveau. De plus, si j'insère un appel à la méthode statique d'une autre classe java avant l'appel de la méthode native tels que,

static 
{ 
System.Load("/root/Desktop/libs/wrapperlibrary"); 
System.out.println("wrapper library loaded"); 
System.out.println(Try.temp()); //where temp is a static method of Try class which returns a string. 

native method call; 

-- 
-- 
} 

puis sortie Try.temp() n'est imprimé.

Quelles pourraient être les raisons possibles du problème dans ces deux approches et comment dois-je procéder?

Answer 1

Il se peut que Java lui-même soit lié à une bibliothèque différente de celle de vos bibliothèques ou que les bibliothèques soient liées différemment/à des bibliothèques différentes.
Vérifiez également si l'une des bibliothèques est liée par rapport à une version de débogage de la glibc (chapeau ce problème sur Windows avec la librairie d'exécution C++). Essayez de relier vos bibliothèques statiquement contre la glibc, ou dans le but d'exclure des possibilités reliant statiquement votre librairie et librairies d'affaires dans une bibliothèque.

Answer 2

J'ai rencontré cette erreur cryptique plusieurs fois. Dans chaque cas, il a été provoqué par le référencement d'un membre de tableau qui se trouvait à l'extérieur de la matrice. La référence n'a pas provoqué de faute de segmentation, car elle était toujours dans les limites d'un autre tableau du programme.Quand je suis allé libérer le tableau, cependant, les choses ont été assez foiré pour lancer cette erreur. Le correctif consistait à vérifier très soigneusement que chaque tableau était correctement alloué, et que les références aux membres du tableau ne sortaient jamais des limites.