Est-il possible de mettre des breakpoints à la modification de certaines plages mémoires dans un debugger ?

Est-il possible de mettre des breakpoints à la modification de certaines plages mémoires dans un debugger ?

by Gabriel Fleischer -
Number of replies: 4
Bonjour,
je suis en train de debugger mon programme pour la mise en place de l'interface visuelle et j'ai quelques problèmes de segmentation fault et de free invalides dans les fonctions de bit_vector. Celle-ci sont appelées avec des arguments invalides par la librairie partagée.

Ce qui est étrange, c'est qu'en regardant les retours de mes fonctions, les bit_vector retournés sont toujours valides. Je penche donc sur un overflow.

Le problème c'est que cet overflow se passe dans la librairie partagée. Et je n'ai pas accès au code source de celle-ci pour exécuter le programme étape par étape et voir quand l'overflow a lieu.

J'ai donc essayé de mettre un breakpoint sur la plage mémoire des bit_vector corrompu pour voir quand ils sont modifiés. Sauf que les solutions que j'ai trouvé sur internet utilisent une combinaison de valgrind et de gbd en remote. Ce qui me dépasse un peu...

J'en viens donc à ma question :

Y a-t-il une manière simple de mettre un breakpoint sur une plage mémoire ?

Et si ce n'est pas le cas, serait-il possible d'avoir accès au code source de la librairie partagée ? Cela nous aiderait beaucoup à comprendre ce qu'il se passe.

Aussi, tous les tests de bit_vector passent.

Merci d'avance.
In reply to Gabriel Fleischer

Re: Est-il possible de mettre des breakpoints à la modification de certaines plages mémoires dans un debugger ?

by Jean-Cédric Chappelier -

au sujet du titre : oui : voir les commandes watch, rwatch et awatch de gdb. Par exemple pour surveiller un write :
watch tab[42]
ou
watch *0x7fffffffdc4c

avoir accès au code : ben, non ; c'est justement pour ça qu'on ne donne qu'une bibliothèque...

autre piste : modifier vos fonctions (en mode débug) pour avoir des « traceurs » (ou des assert sur) des accès demandés/effectués (et ainsi vérifier s'ils sont valides)

In reply to Jean-Cédric Chappelier

Re: Est-il possible de mettre des breakpoints à la modification de certaines plages mémoires dans un debugger ?

by Gabriel Fleischer -

J'ai créé un tableau qui sauvegarde les pointeurs vers les bit_vector lorsqu'ils sont créé et les supprimes lorsqu'ils sont free. Et j'utilise ce tableau pour vérifier que les bit_vector passés en arguments ont bien été créé par le programme. Et aussi vérifier qu'à la fin de chaque méthode, les vecteurs sont encore valides.

Alors, je n'ai pas de problème de vecteurs qui s'invalident pendant les fonctions. Pire, aucun vecteur créé n'est invalidé à un moment.
En fait, la librairie partagée appelle les fonctions de bit_vector avec des pointeurs qui n'ont pas été créés par mon programme...

Aussi, en utilisant valgrind, je tombe sur ça : 

==16917== Memcheck, a memory error detector 
==16917== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==16917== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info 
==16917== Command: ./gbsimulator ./tests/data/blargg_roms/01-special.gb 
==16917== 
==16917== Invalid write of size 4 
==16917==    at 0x40446A1: ??? (in .../done/libcs212gbfinalext.so) 
==16917==    by 0x4046654: ??? (in .../done/libcs212gbfinalext.so)
==16917==    by 0x4046756: ??? (in .../done/libcs212gbfinalext.so) 
==16917==    by 0x4046094: ??? (in .../done/libcs212gbfinalext.so) 
==16917==    by 0x4046250: ??? (in .../done/libcs212gbfinalext.so) 
==16917==    by 0x10AEF8: gameboy_run_until (gameboy.c:83) 
==16917==    by 0x109852: generate_image (gbsimulator.c:44)

Je me dis que quelque part dans la librairie, il y a des écritures sur les pointeurs des vecteurs. Et c'est ce qui casse les vecteur passés en arguments. Mais je ne sais plus du tout où chercher. Auriez-vous une idée de ce qui cause de ce problème ? Merci d'avance.

In reply to Gabriel Fleischer

Re: Est-il possible de mettre des breakpoints à la modification de certaines plages mémoires dans un debugger ?

by Aurélien Clergeot -

Salut, j'avais exactement le même problème que toi, et ça m'a rappellé le problème que j'avais avec le cpu (des erreurs incompréhensibles qui viennent de la library)

=> J'ai échangé la place de mes attributs size et content dans bit_vector, et je n'ai plus eu de SIGSEVs.

Essaye donc de mettre les attributs dans cet ordre :

content,

size

En espérant avoir aidé

In reply to Aurélien Clergeot

Re: Est-il possible de mettre des breakpoints à la modification de certaines plages mémoires dans un debugger ?

by Gabriel Fleischer -

ça a effectivement réglé ce problème. Merci beaucoup !