Prog C - GDB : Corrupt stack

_Pierre_Richard_ Messages postés 11 Statut Membre -  
_Pierre_Richard_ Messages postés 11 Statut Membre -
Bonjour,

J'utilise GDB parce que j'ai un pb juste après une fonction il plante,

A la sortie de la fonction au lieu continué dans ma fontion principal il m'affiche ca :

#0 0x000a2720 in ?? ()
#1 0x00002335 in ?? ()
#2 0x4016272e in ?? ()
#3 0x00000028 in ?? ()
#4 0x00000003 in ?? ()
#5 0x40015610 in ?? ()
#6 0x40014b00 in ?? () from /lib/ld-linux.so.2
#7 0x4001552c in ?? ()
#8 0x4003004e in __errno_location () from /lib/libc.so.6
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

J'ai checké que les librairies appelé compile bien avec l'option -g et aucun strip n'est fait

Avez vous une idée
A voir également:

3 réponses

fiddy Messages postés 11653 Date d'inscription   Statut Contributeur Dernière intervention   1 847
 
Salut,
Commence par poster ton code, l'erreur est peut-être toute simple. ou pas.
PS : n'oublie pas, d'encapsuler ton code entre deux balises code pour plus de lisibilité.
Cdlt
0
_Pierre_Richard_ Messages postés 11 Statut Membre
 
Merci fiddy , j'ai trouvé une corruption mémoire ca a réglé pb :)
0
kilian Messages postés 8854 Statut Modérateur 1 526
 
A la sortie de la fonction au lieu continué dans ma fontion principal il m'affiche ca :

Un petit truc au fait dans ce genre de cas, si tu connais un peu l'assembleur.
Si tu as ça:
int main()
{
    prout();
    return 0;
}

Donc apparemment, au sortir de prout ça plante.
Donc tu démarres gdb avec ton appli:
gdb ./app

Ensuite tu affiches le code assembleur de ta fonction:
disass prout

Repère l'adresse ou tu trouves l'instruction ret:
<0xff000000>  ret

Et tu fais un breakpoint sur cette adresse:
b *0xff000000

Puis tu tapes r pour démarrer le prog.
Une fois que tu es sur le breakpoint, inspecte l'adresse de retour qui est dans esp:
p $esp

Et regarde la valeur, effectivement si elle n'est pas cohérente il faut regarder dans le code assembleur pourquoi. Mais bon si ya moyen de trouver dans le code C, alors c'est mieux. Donc oui il faut que tu postes ton code :-)

A priori vu que ta fonction ne retourne pas au bon endroit, l'erreur au niveau du C devrait être assez visible :-)
0
_Pierre_Richard_ Messages postés 11 Statut Membre
 
Merci les gars,

Dsl pr le code il est hyper long il appelle plein de fonctions qui ne sont pas de moi ... sinon je l'aurai mis sans problème

Pr ma part le programme n'est meme pas multithread dc pas compilé avec pthread , et on le tableau de char que j'avais alloué était apparement trop petit et la fonction qui ecrit dedans ne se preoccupe pas de savoir si la taille du buffer est dépassée ...

killian, mer ci pr le tuto de gdb, je connaissais pas . Pour ma part j'ai fait une petite recherche et j'ai trouvé ce "petit" tuto pour
reconstruire un backtrace sur gdb qd on a ce pb, si jamais ca peut aider ...

http://devpit.org/wiki/GDB
http://devpit.org/wiki/x86ManualBacktrace
0
Char Snipeur Messages postés 10112 Date d'inscription   Statut Contributeur Dernière intervention   1 299
 
Salut.
J'avais une erreur similaire dans deux cas :
- oublie de compiler en liant avec pthread sous linux
- changement minime de compilateur entre .o (a.o était fait avec compil1, et b.o avec compil2) qui n'entrainait une erreur que à l'exécution.
bonne chance
0
kilian Messages postés 8854 Statut Modérateur 1 526
 
C'est le genre de truc qui peut probablement arriver aussi avec des incohérences de conventions de passage de paramètre (stdcall vs cdecl) ou encore quand on fait des trucs bizzares (hooking)...
0