[grisbi-bugs] [Grisbi-0.6.0 0000633]: Segfault à l'ouverture
bugtracker at grisbi.org
bugtracker at grisbi.org
Sun Jan 3 21:24:41 CET 2010
A NOTE has been added to this issue.
======================================================================
http://grisbi.tuxfamily.org/mantis/view.php?id=633
======================================================================
Reported By: gerald
Assigned To:
======================================================================
Project: Grisbi-0.6.0
Issue ID: 633
Category: Main
Reproducibility: always
Severity: crash
Priority: urgent
Status: feedback
Plateforme: Linux
OS: Autre(Other)
Version OS:
Unstable Impact: Yes
Version GTK:
======================================================================
Date Submitted: 09-06-2009 16:40 UTC
Last Modified: 01-03-2010 20:24 UTC
======================================================================
Summary: Segfault à l'ouverture
Description:
Grisbi provoque un segfault sur Mac OS X 10.6 après ouverture de la fenêtre
principale et avant affichage de son contenu.
$ grisbi
Xlib: extension "RANDR" missing on display "/tmp/launch-MNdDwa/:0".
Sun Sep 6 18:34:04 2009 : 15 elements in stack.
0 grisbi 0x0000000100011b87
print_backtrace + 44
1 grisbi 0x0000000100011655
traitement_sigsegv + 733
2 libSystem.B.dylib 0x00007fff87f0014a _sigtramp +
26
3 libgtk-x11-2.0.0.dylib 0x000000010032c69e
gtk_tree_view_column_init + 174
4 grisbi 0x0000000100093fef
gsb_form_widget_check_empty + 281
5 grisbi 0x0000000100051bac
gsb_calendar_entry_changed + 25
6 libgobject-2.0.0.dylib 0x0000000100b97152
g_closure_invoke + 306
7 libgobject-2.0.0.dylib 0x0000000100babbe8
signal_emit_unlocked_R + 2280
8 libgobject-2.0.0.dylib 0x0000000100bad726
g_signal_emit_valist + 2262
9 libgobject-2.0.0.dylib 0x0000000100bad9f5
g_signal_emit_by_name + 437
10 libgtk-x11-2.0.0.dylib 0x00000001001c1f51 end_change +
113
11 libgtk-x11-2.0.0.dylib 0x00000001001c215f
gtk_entry_set_text + 415
12 grisbi 0x0000000100091672
gsb_form_scheduler_clean + 335
13 grisbi 0x0000000100090c3d
gsb_form_scheduler_create + 1653
14 grisbi 0x0000000100089449
gsb_form_create_widgets + 764
======================================================================
----------------------------------------------------------------------
gerald - 09-06-09 16:47
----------------------------------------------------------------------
Sous Mac OS X 10.6 Snow Leopard
GTK 2.16.6
XQuartz 2.3.4 (xorg-server 1.4.2-apple45)
----------------------------------------------------------------------
gerald - 09-13-09 12:28
----------------------------------------------------------------------
Par défaut Snow Leopard est en 64 bits, -arch X86_64.
Si je compile grisbi avec -arch i386, plus de segfault.
Je vais essayer en universal binary...
----------------------------------------------------------------------
pbiava - 09-13-09 13:37
----------------------------------------------------------------------
C'est une bonne nouvelle. Je vais essayer de compiler grisbi sur une
version X86_64 de ma mandriva pour voir si j'ai le même comportement.
----------------------------------------------------------------------
pbiava - 09-18-09 19:07
----------------------------------------------------------------------
J'ai installé la version 64 bits de la Mandriva 2009 sprint et je n'ai pas
rencontré ce plantage.
----------------------------------------------------------------------
gerald - 09-19-09 06:17
----------------------------------------------------------------------
C'est systématique sous Mac OS X Snow Leopard si grisbi n'est pas compilé
avec l'option -arch i386.
Je n'ai pas essayé la 0.5.9 sur ce système pour voir si il y avait le même
problème.
D'autres applications GTK fonctionnent en x86_64.
À l'instant, dernier CVS :
$ opt/bin/grisbi
Xlib: extension "RANDR" missing on display "/tmp/launch-36wEgM/:0".
Sat Sep 19 08:15:51 2009 : 15 elements in stack.
0 grisbi 0x000000010001174b
print_backtrace + 44
1 grisbi 0x0000000100011219
traitement_sigsegv + 733
2 libSystem.B.dylib 0x00007fff8582c0aa _sigtramp +
26
3 libgtk-x11-2.0.0.dylib 0x000000010032c69e
gtk_tree_view_column_init + 174
4 grisbi 0x0000000100093c2b
gsb_form_widget_check_empty + 281
5 grisbi 0x0000000100051770
gsb_calendar_entry_changed + 25
6 libgobject-2.0.0.dylib 0x0000000100b97152
g_closure_invoke + 306
7 libgobject-2.0.0.dylib 0x0000000100babbe8
signal_emit_unlocked_R + 2280
8 libgobject-2.0.0.dylib 0x0000000100bad726
g_signal_emit_valist + 2262
9 libgobject-2.0.0.dylib 0x0000000100bad9f5
g_signal_emit_by_name + 437
10 libgtk-x11-2.0.0.dylib 0x00000001001c1f51 end_change +
113
11 libgtk-x11-2.0.0.dylib 0x00000001001c215f
gtk_entry_set_text + 415
12 grisbi 0x00000001000912ae
gsb_form_scheduler_clean + 335
13 grisbi 0x0000000100090879
gsb_form_scheduler_create + 1705
14 grisbi 0x0000000100089051
gsb_form_create_widgets + 764
----------------------------------------------------------------------
pbiava - 09-19-09 07:04
----------------------------------------------------------------------
En fait je ne trouve pas dans le code un élément qui fait référence à ce
gtk_tree_view_column_init. il faudrait savoir si cet appel se fait avant le
plantage ou après.
je recherche dans le message de plantage une référence à quelque chose
noté 0x0.
----------------------------------------------------------------------
guneeyoufix - 11-18-09 10:37
----------------------------------------------------------------------
Si GTK n'est pas compilé pour une architecture 64 bits, il est à mon avis
possible que ça créée ce genre de problèmes (en particulier si l'OS et le
programme qui l'utilise sont compilés en 64 bits).
A mon avis, c'est du côté de GTK qu'il faut regarder...
----------------------------------------------------------------------
pbiava - 11-27-09 22:21
----------------------------------------------------------------------
J'ai corrigé quelques bugs aléatoires de Grisbi, il faudrait voir si la
version cvs en cours fonctionne mieux.
----------------------------------------------------------------------
pbiava - 12-26-09 17:30
----------------------------------------------------------------------
As-tu le temps de faire un nouveau test ?
----------------------------------------------------------------------
gerald - 12-29-09 06:49
----------------------------------------------------------------------
Testé hier soir, toujours le même problème si grisbi (et l'ensemble des
dépendances) pour l'architecture x86_64 (par défaut sur Snow Leopard si le
processeur est 64 bits) ça plante à l'ouverture avec le même message.
Si je force -arch i386 alors c'est OK. Par contre pour ce faire, il faut
compiler l'ensemble des dépendances soit en universal (X86_64 et i386) ou
soit exclusivement i386 sinon ça plante à la compilation (make).
Ce n'est pas gênant en soit pour générer un binaire fonctionnel puisque la
version i386 fonctionnera sur Mac OS X 10.5 et 10.6 sur plateforme Intel
mais c'est gênant pour le port MacPorts qui par défaut sera compilé en
X86_64 sur Snow Leopard (Mac OS X 10.6).
----------------------------------------------------------------------
pbiava - 12-29-09 21:53
----------------------------------------------------------------------
C'est embêtant de ne pas comprendre ce qui se passe. Il nous faudrait un
développeur sous mac.
----------------------------------------------------------------------
gerald - 01-02-10 13:25
----------------------------------------------------------------------
Je viens de re-faire quelques test avec la version 0.5.9, il s'avère que le
problème existe aussi avec cette version.
Si grisbi (0.5.9) est compilé en universal (x86_64 i386) ou en x86_64 il
segfault aussi à l'ouverture.
Il est fort possible que Grisbi ne soit pas directement en cause mais que
ce soit bel et bien dût à certaines librairies compilées uniquement en
i386.
Je suis en train de voir comment forcer le port MacPorts à compiler en
i386 uniquement.
----------------------------------------------------------------------
pbiava - 01-03-10 08:43
----------------------------------------------------------------------
C'est rassurant que grisbi ne soit pas obligatoirement en cause. Je
n'aurais pas besoin de m'acheter un mac.
----------------------------------------------------------------------
gerald - 01-03-10 20:24
----------------------------------------------------------------------
C'eut été un excellent prétexte. ;-)
Je confirme qu'effectivement quelques dépendances ne se compilent qu'en
i386 et du coup si on compile Grisbi pour l'architecture x86_64 ça ne
fonctionne pas.
Je viens de soumettre la modification du Portfile pour la 0.5.9 et ai
modifié le Portfile de la 0.6.0rc1 pour que ça force la compilation en
i386.
Il faut bien entendu que tout ai été compilé en universal binary ou
exclusivement en i386.
D'ailleurs les binaires produits sur Leopard (10.5) fonctionnent sans
soucis sur Snow Leopard (10.6).
Je suis en train de produire les paquets Grisbi.app avec aqua pour 10.5
Intel et PPC.
Par contre le bug 830 est assez agaçant, du coup les versions Grisbi.app
ne fonctionnent pas out of the box.
Issue History
Date Modified Username Field Change
======================================================================
09-06-09 16:40 gerald New Issue
09-06-09 16:47 gerald Note Added: 0001142
09-13-09 12:28 gerald Note Added: 0001143
09-13-09 13:37 pbiava Note Added: 0001144
09-18-09 12:14 draaxk Issue Monitored: draaxk
09-18-09 19:07 pbiava Note Added: 0001153
09-19-09 06:17 gerald Note Added: 0001154
09-19-09 07:04 pbiava Note Added: 0001155
11-18-09 10:37 guneeyoufix Note Added: 0001325
11-25-09 17:50 guneeyoufix Plateforme => Linux
11-25-09 17:50 guneeyoufix Status new => confirmed
11-27-09 22:21 pbiava Note Added: 0001370
12-26-09 17:30 pbiava Note Added: 0001504
12-26-09 17:30 pbiava Status confirmed => feedback
12-29-09 06:49 gerald Note Added: 0001532
12-29-09 21:53 pbiava Note Added: 0001535
01-02-10 13:25 gerald Note Added: 0001576
01-03-10 08:43 pbiava Note Added: 0001579
01-03-10 20:24 gerald Note Added: 0001595
======================================================================
More information about the bugsreports
mailing list