Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
James Kanze
On May 15, 1:19 pm, (Bruno Causse) wrote:
j'ai deux soucis, que je n'arrive pas a comprendre :(
mon programme c++ est compilé avec gcc 4.2.0 et debuggé avec GNU gdb 6.3.50-20050815 (Apple version gdb-962).
1) au lancement du debuggeur j'ai
run &"warning: posix_spawn failed, trying execvp, error: 86n" [Switching to process 1629 local thread 0x2d03] Running
que signfie ce warning?
dans errno.h #define EBADARCH 86 /* Bad CPU type in executable */
Une incompatibilité entre la compilation de gdb et la version de ton OS ? posix_spawn n'a été ajouté qu'en Unix 03 (Posix 1003.1,2004) : dans la pratique, beaucoup de systèmes courants ne l'implémentent pas encore. (Solaris n'a posix_spawn que depuis Solaris 10, par exemple. Alors que dans l'industrie, on trouve encore beaucoup de Solaris 8 et 9.)
(Pour aller plus loin, il faudrait regarder les sources de gdb. A priori, le seul processus fils auquel je m'attendrais dans gdb, c'est le processus à débugger. Et je ne vois pas trop comment on utiliserait posix_spawn pour le démarrer, étant donné qu'il faut bien que le fils appelle ptrace entre le fork et le exec, afin que le parent puisse intervenir immédiatement après l'exec pour mettre les points d'arrêt.)
2) a la fin de l'execution du programme, j'ai un comportement indefini (1 fois sur 10)
Roxane(1223,0x7fff707bb700) malloc: *** error for object 0x100243180: double free *** set a breakpoint in malloc_error_break to debug
en posant le breakpoint et en remontant la pile d'information j'arrive a
#4 0x00005a61 in std::string::_M_rep at basic_string.h:123 #5 0x00005a61 in ~basic_string [inlined] at basic_string.h:472
que puis je conclure?
Que tu as un problème quelque part:-). Sérieusement, c'est difficile à dire comme ça ; probablement, tu te sers quelque part de la mémoire après l'avoir deletée. Ensuite, std::string l'alloue, puis tu le deletes une deuxième fois, et quand std::string le delete, tu as l'erreur ci-dessus.
Essayer d'exécuter avec valgrind, Purify, ou quelque chose du genre.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On May 15, 1:19 pm, PasDeS...@free.fr (Bruno Causse) wrote:
j'ai deux soucis, que je n'arrive pas a comprendre :(
mon programme c++ est compilé avec gcc 4.2.0 et debuggé avec GNU gdb
6.3.50-20050815 (Apple version gdb-962).
1) au lancement du debuggeur j'ai
run
&"warning: posix_spawn failed, trying execvp, error: 86n"
[Switching to process 1629 local thread 0x2d03]
Running
que signfie ce warning?
dans errno.h
#define EBADARCH 86 /* Bad CPU type in executable */
Une incompatibilité entre la compilation de gdb et la version de
ton OS ? posix_spawn n'a été ajouté qu'en Unix 03 (Posix
1003.1,2004) : dans la pratique, beaucoup de systèmes courants
ne l'implémentent pas encore. (Solaris n'a posix_spawn que
depuis Solaris 10, par exemple. Alors que dans l'industrie, on
trouve encore beaucoup de Solaris 8 et 9.)
(Pour aller plus loin, il faudrait regarder les sources de gdb.
A priori, le seul processus fils auquel je m'attendrais dans
gdb, c'est le processus à débugger. Et je ne vois pas trop
comment on utiliserait posix_spawn pour le démarrer, étant donné
qu'il faut bien que le fils appelle ptrace entre le fork et le
exec, afin que le parent puisse intervenir immédiatement après
l'exec pour mettre les points d'arrêt.)
2) a la fin de l'execution du programme, j'ai un comportement indefini
(1 fois sur 10)
Roxane(1223,0x7fff707bb700) malloc: *** error for object 0x100243180:
double free
*** set a breakpoint in malloc_error_break to debug
en posant le breakpoint et en remontant la pile d'information
j'arrive a
#4 0x00005a61 in std::string::_M_rep at basic_string.h:123
#5 0x00005a61 in ~basic_string [inlined] at basic_string.h:472
que puis je conclure?
Que tu as un problème quelque part:-). Sérieusement, c'est
difficile à dire comme ça ; probablement, tu te sers quelque
part de la mémoire après l'avoir deletée. Ensuite, std::string
l'alloue, puis tu le deletes une deuxième fois, et quand
std::string le delete, tu as l'erreur ci-dessus.
Essayer d'exécuter avec valgrind, Purify, ou quelque chose du
genre.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
j'ai deux soucis, que je n'arrive pas a comprendre :(
mon programme c++ est compilé avec gcc 4.2.0 et debuggé avec GNU gdb 6.3.50-20050815 (Apple version gdb-962).
1) au lancement du debuggeur j'ai
run &"warning: posix_spawn failed, trying execvp, error: 86n" [Switching to process 1629 local thread 0x2d03] Running
que signfie ce warning?
dans errno.h #define EBADARCH 86 /* Bad CPU type in executable */
Une incompatibilité entre la compilation de gdb et la version de ton OS ? posix_spawn n'a été ajouté qu'en Unix 03 (Posix 1003.1,2004) : dans la pratique, beaucoup de systèmes courants ne l'implémentent pas encore. (Solaris n'a posix_spawn que depuis Solaris 10, par exemple. Alors que dans l'industrie, on trouve encore beaucoup de Solaris 8 et 9.)
(Pour aller plus loin, il faudrait regarder les sources de gdb. A priori, le seul processus fils auquel je m'attendrais dans gdb, c'est le processus à débugger. Et je ne vois pas trop comment on utiliserait posix_spawn pour le démarrer, étant donné qu'il faut bien que le fils appelle ptrace entre le fork et le exec, afin que le parent puisse intervenir immédiatement après l'exec pour mettre les points d'arrêt.)
2) a la fin de l'execution du programme, j'ai un comportement indefini (1 fois sur 10)
Roxane(1223,0x7fff707bb700) malloc: *** error for object 0x100243180: double free *** set a breakpoint in malloc_error_break to debug
en posant le breakpoint et en remontant la pile d'information j'arrive a
#4 0x00005a61 in std::string::_M_rep at basic_string.h:123 #5 0x00005a61 in ~basic_string [inlined] at basic_string.h:472
que puis je conclure?
Que tu as un problème quelque part:-). Sérieusement, c'est difficile à dire comme ça ; probablement, tu te sers quelque part de la mémoire après l'avoir deletée. Ensuite, std::string l'alloue, puis tu le deletes une deuxième fois, et quand std::string le delete, tu as l'erreur ci-dessus.
Essayer d'exécuter avec valgrind, Purify, ou quelque chose du genre.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
