problème de "Bus error" avec un programme GTK sous Mac OS X Intel
2 réponses
Gérald Niel
Bonjour,
je suis le mainteneur des paquets binaires et macports de Grisbi
<http://www.grisbi.org>, ce programme est développé sous Linux en C et
en utilisant GTK.
Je ne suis pas developpeur, mais je poste ce message pour essyer
d'aiguiller les developpeurs sur une piste.
Il y a un bug reproductible à coup sûr, on ouvre une fenêtre (en
l'occurence d'édition des préférences générales du logiciel) et on
essaie de la fermer. Ça provoque à coup sûr un "Bus error" et ça ferme
le logiciel.
Voici la sortie de gdb :
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 0x00000000 in
?? ()
pour moi elle n'est pas très parlante, est-ce qu'il y a un moyen au
moment du configure ou make de demander la compilation avec les
symboles de débogages si ce n'est fait par défaut pour obtenir une
sortie de gdp plus parlante ?
À noter que ce bug n'intervient que sur plateforme Intel (un Core 2
Duo 2.16 GHz). J'ai compilé le programme sous la même version de Mac
OS X (10.5.7) avec les mêmes librairies dont la même version de GTK
2.16.1 le tout installé avec la même version de MacPorts 1.710 sur une
machine PPC et il n'y a pas ce bug.
Le mode de débogage du logiciel provoque cette sortie :
Sun May 24 09:24:55 2009 : Debug - parametres.c:217:preferences -
14673672
Sun May 24 09:24:55 2009 : Debug -
traitement_variables.c:178:modification_fichier - 1
Sun May 24 09:24:55 2009 : Debug -
parametres.c:834:gsb_config_backup_dir_chosen -
/Users/gerald/.local/share/grisbi
(grisbi:438): Gtk-WARNING **: Impossible de trouver le type de
moniteur de répertoire local par défaut
Sun May 24 09:24:56 2009 : Debug -
parametres.c:834:gsb_config_backup_dir_chosen -
/Users/gerald/.local/share/grisbi
Bus error
Le Gtk-WARNING est aussi présent sur la version PPC.
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
Gérald Niel
Le Dimanche 24 mai 2009 à 07:33 UTC, Gérald Niel écrivait sur fr.comp.sys.mac.programmation :
Il y a un bug reproductible à coup sûr, on ouvre une fenêtre (en l'occurence d'édition des préférences générales du logiciel) et on essaie de la fermer. Ça provoque à coup sûr un "Bus error" et ça ferme le logiciel. Voici la sortie de gdb :
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 0x00000000 in ?? ()
Je cite un des développeurs, après avoir isoler ce qui génère le bug :
C'est propre à gtk quand un widget est détruit on appelle la fonction gtk_widget_destroyed (). Elle est chargée de mettre le pointeur sur le widget à NULL. Ceci évite d'avoir de multiples copies du widget.
Je me demande si on en fait pas un usage immodéré car je pense que gtk libère lui même la mémoire qu'il utilise.
Si quelqu'un a une idée ou un conseil, je transmettrais, ils ne suivent pas les groupes usenet (pas fautes d'avoir essayé de les convaincre). Sinon vous avez l'échange sur grisbi.devel (sur news.grisbi.org, news.gegeweb.org, news.orange.fr pour les serveurs que je connais et qui distribuent grisbi.*).
@+ -- Gérald Niel <http://news.gegeweb.org>
Le Dimanche 24 mai 2009 à 07:33 UTC, Gérald Niel écrivait sur
fr.comp.sys.mac.programmation :
Il y a un bug reproductible à coup sûr, on ouvre une fenêtre (en
l'occurence d'édition des préférences générales du logiciel) et on
essaie de la fermer. Ça provoque à coup sûr un "Bus error" et ça ferme
le logiciel.
Voici la sortie de gdb :
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 0x00000000 in
?? ()
Je cite un des développeurs, après avoir isoler ce qui génère le bug :
C'est propre à gtk quand un widget est détruit on appelle la fonction
gtk_widget_destroyed (). Elle est chargée de mettre le pointeur sur le
widget à NULL. Ceci évite d'avoir de multiples copies du widget.
Je me demande si on en fait pas un usage immodéré car je pense que gtk
libère lui même la mémoire qu'il utilise.
Si quelqu'un a une idée ou un conseil, je transmettrais, ils ne
suivent pas les groupes usenet (pas fautes d'avoir essayé de les
convaincre).
Sinon vous avez l'échange sur grisbi.devel (sur news.grisbi.org,
news.gegeweb.org, news.orange.fr pour les serveurs que je connais et
qui distribuent grisbi.*).
Le Dimanche 24 mai 2009 à 07:33 UTC, Gérald Niel écrivait sur fr.comp.sys.mac.programmation :
Il y a un bug reproductible à coup sûr, on ouvre une fenêtre (en l'occurence d'édition des préférences générales du logiciel) et on essaie de la fermer. Ça provoque à coup sûr un "Bus error" et ça ferme le logiciel. Voici la sortie de gdb :
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 0x00000000 in ?? ()
Je cite un des développeurs, après avoir isoler ce qui génère le bug :
C'est propre à gtk quand un widget est détruit on appelle la fonction gtk_widget_destroyed (). Elle est chargée de mettre le pointeur sur le widget à NULL. Ceci évite d'avoir de multiples copies du widget.
Je me demande si on en fait pas un usage immodéré car je pense que gtk libère lui même la mémoire qu'il utilise.
Si quelqu'un a une idée ou un conseil, je transmettrais, ils ne suivent pas les groupes usenet (pas fautes d'avoir essayé de les convaincre). Sinon vous avez l'échange sur grisbi.devel (sur news.grisbi.org, news.gegeweb.org, news.orange.fr pour les serveurs que je connais et qui distribuent grisbi.*).
@+ -- Gérald Niel <http://news.gegeweb.org>
Gérald Niel
(supersedes) (x-post fr.comp.lang.c, suivi sur fr.comp.sys.mac.programmation)
Le Dimanche 24 mai 2009 à 07:33 UTC, Gérald Niel écrivait sur fr.comp.sys.mac.programmation :
(à propos de la version CVS de Grisbi sur Mac OS X / Intel)
Il y a un bug reproductible à coup sûr, on ouvre une fenêtre (en l'occurence d'édition des préférences générales du logiciel) et on essaie de la fermer. Ça provoque à coup sûr un "Bus error" et ça ferme le logiciel. Voici la sortie de gdb :
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 0x00000000 in ?? ()
Je cite un des développeurs, après avoir isolé ce qui génère le bug :
C'est propre à gtk quand un widget est détruit on appelle la fonction gtk_widget_destroyed (). Elle est chargée de mettre le pointeur sur le widget à NULL. Ceci évite d'avoir de multiples copies du widget.
Je me demande si on en fait pas un usage immodéré car je pense que gtk libère lui même la mémoire qu'il utilise.
Si quelqu'un a une idée ou un conseil, je transmettrais, ils ne suivent pas les groupes usenet (pas fautes d'avoir essayé de les convaincre). Sinon vous avez l'échange sur grisbi.devel (sur news.grisbi.org, news.gegeweb.org, news.orange.fr pour les serveurs que je connais et qui distribuent grisbi.*).
@+ -- Gérald Niel <http://news.gegeweb.org>
(supersedes)
(x-post fr.comp.lang.c, suivi sur fr.comp.sys.mac.programmation)
Le Dimanche 24 mai 2009 à 07:33 UTC, Gérald Niel écrivait sur
fr.comp.sys.mac.programmation :
(à propos de la version CVS de Grisbi sur Mac OS X / Intel)
Il y a un bug reproductible à coup sûr, on ouvre une fenêtre (en
l'occurence d'édition des préférences générales du logiciel) et on
essaie de la fermer. Ça provoque à coup sûr un "Bus error" et ça ferme
le logiciel.
Voici la sortie de gdb :
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 0x00000000 in
?? ()
Je cite un des développeurs, après avoir isolé ce qui génère le bug :
C'est propre à gtk quand un widget est détruit on appelle la fonction
gtk_widget_destroyed (). Elle est chargée de mettre le pointeur sur le
widget à NULL. Ceci évite d'avoir de multiples copies du widget.
Je me demande si on en fait pas un usage immodéré car je pense que gtk
libère lui même la mémoire qu'il utilise.
Si quelqu'un a une idée ou un conseil, je transmettrais, ils ne
suivent pas les groupes usenet (pas fautes d'avoir essayé de les
convaincre).
Sinon vous avez l'échange sur grisbi.devel (sur news.grisbi.org,
news.gegeweb.org, news.orange.fr pour les serveurs que je connais et
qui distribuent grisbi.*).
(supersedes) (x-post fr.comp.lang.c, suivi sur fr.comp.sys.mac.programmation)
Le Dimanche 24 mai 2009 à 07:33 UTC, Gérald Niel écrivait sur fr.comp.sys.mac.programmation :
(à propos de la version CVS de Grisbi sur Mac OS X / Intel)
Il y a un bug reproductible à coup sûr, on ouvre une fenêtre (en l'occurence d'édition des préférences générales du logiciel) et on essaie de la fermer. Ça provoque à coup sûr un "Bus error" et ça ferme le logiciel. Voici la sortie de gdb :
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 0x00000000 in ?? ()
Je cite un des développeurs, après avoir isolé ce qui génère le bug :
C'est propre à gtk quand un widget est détruit on appelle la fonction gtk_widget_destroyed (). Elle est chargée de mettre le pointeur sur le widget à NULL. Ceci évite d'avoir de multiples copies du widget.
Je me demande si on en fait pas un usage immodéré car je pense que gtk libère lui même la mémoire qu'il utilise.
Si quelqu'un a une idée ou un conseil, je transmettrais, ils ne suivent pas les groupes usenet (pas fautes d'avoir essayé de les convaincre). Sinon vous avez l'échange sur grisbi.devel (sur news.grisbi.org, news.gegeweb.org, news.orange.fr pour les serveurs que je connais et qui distribuent grisbi.*).
