je cherche des pistes pour comprendre pourquoi mon programme
me sort un segmentation fault.
les symptomes sont les suivants :
dans une fonction j'ai un truc comme ça :
dummyclasse* ptr = new dummyclasse(1,2);
qui, apparemment, provoque un segmentation fault.
j'ai remplacé ceci par :
dummyclasse* ptr = (dummyclasse*)malloc(sizeof(dummyclasse));
ce qui me provoque le même segfault
en revanche :
dummyclasse a(1,2);
ne pose pas de problème
A priori, je dirais que la mémoire est déjà corrompue avant l'appel à malloc ou new. Regarde du coté des écritures sur des objets alloués dynamiquement précédent l'appel.
Si le code unique :
! class dummyclasse { /* ... */ }; ! ! int main() { ! dummyclasse * p = new dummyclasse (1, 2); ! delete p; ! }
plante, une étude du code du constructeur est nécéssaire pour déterminer le problème.
xavier
fabrizio a dit le 10/02/2005 12:01:
auriez vous quelque idée ?
A priori, je dirais que la mémoire est déjà corrompue avant l'appel à
malloc ou new.
Regarde du coté des écritures sur des objets alloués dynamiquement
précédent l'appel.
Si le code unique :
! class dummyclasse { /* ... */ };
!
! int main() {
! dummyclasse * p = new dummyclasse (1, 2);
! delete p;
! }
plante, une étude du code du constructeur est nécéssaire pour déterminer
le problème.
A priori, je dirais que la mémoire est déjà corrompue avant l'appel à malloc ou new. Regarde du coté des écritures sur des objets alloués dynamiquement précédent l'appel.
Si le code unique :
! class dummyclasse { /* ... */ }; ! ! int main() { ! dummyclasse * p = new dummyclasse (1, 2); ! delete p; ! }
plante, une étude du code du constructeur est nécéssaire pour déterminer le problème.
xavier
fabrizio
A priori, je dirais que la mémoire est déjà corrompue avant l'appel à malloc ou new.
ca veut dire quoi que la mémoire est "corrompue" ? ca peut venir de quoi ?
Regarde du coté des écritures sur des objets alloués dynamiquement précédent l'appel.
Si le code unique :
! class dummyclasse { /* ... */ }; ! ! int main() { ! dummyclasse * p = new dummyclasse (1, 2); ! delete p; ! }
plante, une étude du code du constructeur est nécéssaire pour déterminer le problème.
ah oui j'avais oublié. ceci fonctionne. donc je pense que le problème n'est pas dans le constructeur. ceci étant corroboré par la fait que un simple malloc provoque le même segfault.
merci pour ta réponse
A priori, je dirais que la mémoire est déjà corrompue avant l'appel à
malloc ou new.
ca veut dire quoi que la mémoire est "corrompue" ?
ca peut venir de quoi ?
Regarde du coté des écritures sur des objets alloués dynamiquement
précédent l'appel.
Si le code unique :
! class dummyclasse { /* ... */ };
!
! int main() {
! dummyclasse * p = new dummyclasse (1, 2);
! delete p;
! }
plante, une étude du code du constructeur est nécéssaire pour déterminer
le problème.
ah oui j'avais oublié. ceci fonctionne.
donc je pense que le problème n'est pas dans le constructeur.
ceci étant corroboré par la fait que un simple malloc provoque le même
segfault.
A priori, je dirais que la mémoire est déjà corrompue avant l'appel à malloc ou new.
ca veut dire quoi que la mémoire est "corrompue" ? ca peut venir de quoi ?
Regarde du coté des écritures sur des objets alloués dynamiquement précédent l'appel.
Si le code unique :
! class dummyclasse { /* ... */ }; ! ! int main() { ! dummyclasse * p = new dummyclasse (1, 2); ! delete p; ! }
plante, une étude du code du constructeur est nécéssaire pour déterminer le problème.
ah oui j'avais oublié. ceci fonctionne. donc je pense que le problème n'est pas dans le constructeur. ceci étant corroboré par la fait que un simple malloc provoque le même segfault.
merci pour ta réponse
flure
A priori, je dirais que la mémoire est déjà corrompue avant l'appel à malloc ou new.
ca veut dire quoi que la mémoire est "corrompue" ? ca peut venir de quoi ?
Ça veut dire que tu as une fuite mémoire, ou un débordement quelque part avant ton new. Utilise un outil comme Valgrind pour le repérer ... Si tu es sur un système Linux, tu as Alleyoop qui est un front-end à Valgrind, très pratique à utiliser. Personnellement j'utilise régulièrement ce genre d'outils pour corriger les erreurs (en général d'inattention) dans mes allocations/déallocations.
-- Florent "flure" C. http://flure.free.fr
A priori, je dirais que la mémoire est déjà corrompue avant l'appel à
malloc ou new.
ca veut dire quoi que la mémoire est "corrompue" ?
ca peut venir de quoi ?
Ça veut dire que tu as une fuite mémoire, ou un débordement quelque part
avant ton new. Utilise un outil comme Valgrind pour le repérer ...
Si tu es sur un système Linux, tu as Alleyoop qui est un front-end à
Valgrind, très pratique à utiliser.
Personnellement j'utilise régulièrement ce genre d'outils pour corriger
les erreurs (en général d'inattention) dans mes allocations/déallocations.
A priori, je dirais que la mémoire est déjà corrompue avant l'appel à malloc ou new.
ca veut dire quoi que la mémoire est "corrompue" ? ca peut venir de quoi ?
Ça veut dire que tu as une fuite mémoire, ou un débordement quelque part avant ton new. Utilise un outil comme Valgrind pour le repérer ... Si tu es sur un système Linux, tu as Alleyoop qui est un front-end à Valgrind, très pratique à utiliser. Personnellement j'utilise régulièrement ce genre d'outils pour corriger les erreurs (en général d'inattention) dans mes allocations/déallocations.
-- Florent "flure" C. http://flure.free.fr
xavier
fabrizio a dit le 10/02/2005 12:26:
ca veut dire quoi que la mémoire est "corrompue" ?
Pour pouvoir fonctionner correctement malloc maintient une structure de donnée, invisible pour l'utilisateur, qui lui indique quelle zone de la mémoire est disponible ou indisponible.
Une action dans ton programme a écrit une donnée dans cette structure. Elle est donc corrompue et entraîne le plantage de malloc.
ca peut venir de quoi ?
La plupart du temps, il s'agit d'une écriture hors limite. Par exemple :
! char * p = malloc(10); ! p[-1] = 0; // écriture avant la zone, grand risque de corruption ! p[10] = 0; // écriture après la zone, idem.
Pour abonder dans le sens de flure, il existe tout un tas de bibliothèque et outils qui te permettent de vérifier de manière automatique ce genre d'erreur. Valgrind en est un particulièrement bien fichu.
xavier
fabrizio a dit le 10/02/2005 12:26:
ca veut dire quoi que la mémoire est "corrompue" ?
Pour pouvoir fonctionner correctement malloc maintient une structure de
donnée, invisible pour l'utilisateur, qui lui indique quelle zone de la
mémoire est disponible ou indisponible.
Une action dans ton programme a écrit une donnée dans cette structure.
Elle est donc corrompue et entraîne le plantage de malloc.
ca peut venir de quoi ?
La plupart du temps, il s'agit d'une écriture hors limite. Par exemple :
! char * p = malloc(10);
! p[-1] = 0; // écriture avant la zone, grand risque de corruption
! p[10] = 0; // écriture après la zone, idem.
Pour abonder dans le sens de flure, il existe tout un tas de
bibliothèque et outils qui te permettent de vérifier de manière
automatique ce genre d'erreur. Valgrind en est un particulièrement bien
fichu.
ca veut dire quoi que la mémoire est "corrompue" ?
Pour pouvoir fonctionner correctement malloc maintient une structure de donnée, invisible pour l'utilisateur, qui lui indique quelle zone de la mémoire est disponible ou indisponible.
Une action dans ton programme a écrit une donnée dans cette structure. Elle est donc corrompue et entraîne le plantage de malloc.
ca peut venir de quoi ?
La plupart du temps, il s'agit d'une écriture hors limite. Par exemple :
! char * p = malloc(10); ! p[-1] = 0; // écriture avant la zone, grand risque de corruption ! p[10] = 0; // écriture après la zone, idem.
Pour abonder dans le sens de flure, il existe tout un tas de bibliothèque et outils qui te permettent de vérifier de manière automatique ce genre d'erreur. Valgrind en est un particulièrement bien fichu.
xavier
flure
! p[-1] = 0; // écriture avant la zone, grand risque de corruption
C'est possible, ça ??? Je pensais qu'un index de tableau était obligatoirement unsigned int ?
C'est une question, pas une critique, bien sûr :)
-- Florent "flure" C. http://flure.free.fr
! p[-1] = 0; // écriture avant la zone, grand risque de corruption
C'est possible, ça ???
Je pensais qu'un index de tableau était obligatoirement unsigned int ?
"flure" a écrit dans le message de news: 420b5494$0$5212$
! p[-1] = 0; // écriture avant la zone, grand risque de corruption
C'est possible, ça ??? Je pensais qu'un index de tableau était obligatoirement unsigned int ?
non, un entier étant par défaut signé, il est logique que [] attende un int.
(donc signed int).
Jean-Marc Bourguet
flure writes:
! p[-1] = 0; // écriture avant la zone, grand risque de corruption
C'est possible, ça ???
Oui.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
flure <hamiral@hamham.fr> writes:
! p[-1] = 0; // écriture avant la zone, grand risque de corruption
C'est possible, ça ???
Oui.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
! p[-1] = 0; // écriture avant la zone, grand risque de corruption
C'est possible, ça ???
Oui.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
