problème de "Bus error" avec un programme GTK sous Mac OS X Intel

Le
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.

@+
--
Gérald Niel
<http://news.gegeweb.org>
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Gérald Niel
Le #19399811
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.

Voici un exemple de l'appel de la fonction :

g_signal_connect ( G_OBJECT (fenetre_preferences ),
"destroy",
G_CALLBACK (gtk_widget_destroyed),
&fenetre_preferences );

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
Gérald Niel
Le #19399821
(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.

Voici un exemple de l'appel de la fonction :

g_signal_connect ( G_OBJECT (fenetre_preferences ),
"destroy",
G_CALLBACK (gtk_widget_destroyed),
&fenetre_preferences );

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
Publicité
Poster une réponse
Anonyme