__libc_lock_lock est segfaulting

Question

Je travaille sur un morceau de code qui utilise des expressions régulières dans c.

Tous les éléments regex utilisent la bibliothèque standard regex c.

Sur la ligne 246 de regexec.c, la ligne est

__libc_lock_lock(dfa->lock); 

Mon programme est segfaulting ici et je ne peux pas comprendre pourquoi. J'essayais de trouver où __libc_lock_lock a été défini et il s'avère qu'il s'agit d'une macro dans bits/libc-lock.h. Cependant, la macro n'est pas réellement définie pour être quelque chose, juste définie.

Deux questions:

1) Où est le code qui est exécuté lorsque __libc_lock_lock est appelé (je sais que ce doit être remplacé par quelque chose mais je ne sais pas où ce serait

2). dfa est un objet re_dfa_t qui est casté à partir d'une chaîne de caractères qui est le membre du type d'objet regex_t, il n'aura aucun verrou de membre. Est-ce ce qui est censé arriver?

Il coutures vraiment il y a une sorte de magie qui se passe ici avec ce __libc_lock_lock

Answer 1

Si le segfault est libc alors vous pouvez être 99,9% sûr de ce qui suit:

1. Vous sont en train de faire quelque chose de mal avec l'API
2. Vous avez à un moment donné de la mémoire corrompu ou corrompu utilisé par libc, et c'est un effet retardé. (Merci Tyler!)
3. Vous faites quelque chose qui pousse la capacité
4. de l'API Vous êtes un développeur de tester le tronc en cours avec de nouveaux changements dans la mise en œuvre de l'API

Je soupçonne que la première est la cause . La publication de votre utilisation de l'API et de la version de votre bibliothèque peut vous aider. L'API Regexp dans libc est assez stable.

Regardez le débogage avec gdb pour trouver un chemin de trace de la pile l'exécution menant à la segfault et installer les packages glibc-devel pour les symboles. Si le segfault est en (ou hors) de libc ... alors vous avez fait quelque chose de mal (pas un pointeur initialisé opaque par exemple)

[aiden@devbox ~]$ gdb ./myProgram 
(gdb) r 
... Loads of stuff, segfault info .. 
(gdb) bt 

imprimera la pile et fonction des noms qui a conduit à la SEGAULT. Compilez votre source avec l'indicateur de débogage '-g' pour conserver les informations de débogage importantes. Obtenez une source faisant autorité pour l'utilisation/les exemples de l'API!

Bonne chance

Answer 2

exécuter votre code dans gdb jusqu'à ce que vous arriviez à la segfault. Ensuite, faites un backtrace pour savoir où c'était.

Voici l'ensemble des commandes que vous tapera faire ceci:

gdb myprogram 
run 
***Make it crash*** 
backtrace 

frappe backtrace imprimera la pile d'appels et vous montrer quel chemin le code a pris pour arriver au point où il est segfaulting .

Vous pouvez monter et descendre dans la pile de votre code en tapant 'up' ou 'down' respectivement. Vous pouvez ensuite examiner les variables dans cette étendue.

Ainsi par exemple, si votre commande imprime de backtrace ceci:

linux_black_magic 
more_linux 
libc 
libc 
yourcode.c 

Tapez quelques fois « up » de sorte que le cadre de pile est dans votre code au lieu de Linux années. Vous pouvez ensuite examiner les variables et la mémoire sur lesquelles votre programme fonctionne. Pour ce faire:

print VariableName 
x/10 &Variable 

qui imprimera la valeur de la variable, puis imprime un vidage hexadécimal de la mémoire à partir de la variable.

Voici quelques techniques générales à utiliser avec gdb et le débogage, publiez plus de détails pour des réponses plus détaillées.

Answer 3

En réponse à votre première question:

La macro est définie dans le libc-lock.h; son chemin relatif est sysdeps/mach/bits sur la libération de la glibc que j'utilise (2.2.5). Les lignes 67/68 de ce fichier sont

/* Lock the named lock variable. */ 
#define __libc_lock_lock(NAME) __mutex_lock (&(NAME))