[grisbi-devel] OSX: bug et proposition de fix
Pierre Biava
pierre.biava at orange.fr
Wed Oct 11 10:42:13 CEST 2017
nl at haplo.info a écrit le 11/10/2017 à 08:49 :
Re,
> Bonjour,
>
> il s'agit de la dernière release d'OSX: 10.13. (pas de soucis sur 10.12)
> Grisbi ne fonctionnait plus pour un pb de conflit de bibliothèque
> dynamique => pas de lancement de l'exe, plantage pour cause de
> bibliothèque plus dispo.
>
> Le reste de mon email concernait la version "master" recompilée en
> 10.13 avec un environnement de dev remis à jour.
Du coup tu es passé en version GTK3 et en version 1.1.0 de grisbi. Il
faudrait que tu compiles la version de mon dépôt plutôt que le dépôt
officiel :
https://github.com/pierre-biava/grisbi.git
Sinon donne nous la version de gtk utilisée. Il me semble que ludovic
m'a dit qu'il y avait un problème avec gtk3.
Bonne journée.
>
> A+
>
> Le 2017-10-10 10:20, Pierre Biava a écrit :
>> Nicolas LAURENT a écrit le 08/10/2017 à 18:55 :
>>
>> Bonjour,
>>
>>> Bonjour à tous,
>>>
>>> avec la montée de version d’OSX, mon grisbi (stable) ne fonctionnait
>>> plus… J’ai du me résoudre à recompiler et je suis parti du dépôt
>>> GitHub.
>>
>> Tu peux nous donner des précisions sur la version d'OSX et décrire ce
>> que tu vois quand ça plante ?
>>
>> La page d'accueil est-elle affichée ?
>>
>> Quel est le message affiché en bas de la fenêtre de grisbi ?
>> Normalement on doit avoir terminé à la fin de la page home.
>>> Tout marchait bien. Mais voila, des opérations sont arrivées à
>>> échéance et au lancement j’obtiens un
>>>
>>> Sun Oct 8 18:36:47 2017 : 15 elements in stack.
>>> 0 grisbi 0x000000010531c11a
>>> debug_print_backtrace + 58
>>> 1 grisbi 0x000000010531c03d
>>> debug_traitement_sigsegv + 957
>>> 2 libsystem_platform.dylib 0x00007fff6d798f5a
>>> _sigtramp + 26
>>> 3 libsystem_c.dylib 0x00007fff6d5a5c7c
>>> __sfvwrite + 816
>>> 4 libgtk-3.0.dylib 0x0000000105a51494
>>> gtk_box_pack_start + 52
>>> 5 grisbi 0x00000001052e51d1
>>> gsb_main_page_update_finished_scheduled_transactions + 817
>>> 6 grisbi 0x00000001053ca572
>>> gsb_scheduler_increase_scheduled + 258
>>> 7 grisbi 0x00000001053cad3a
>>> gsb_scheduler_check_scheduled_transactions_time_limit + 394
>>> 8 grisbi 0x00000001052e323f
>>> update_liste_echeances_manuelles_accueil + 95
>>> 9 grisbi 0x00000001052e29bb
>>> mise_a_jour_accueil + 27
>>> 10 grisbi 0x0000000105400177
>>> gsb_gui_navigation_select_line + 327
>>> 11 libgobject-2.0.0.dylib 0x000000010679df60
>>> g_cclosure_marshal_VOID__VOIDv + 176
>>> 12 libgobject-2.0.0.dylib 0x000000010679a4eb
>>> _g_closure_invoke_va + 539
>>> 13 libgobject-2.0.0.dylib 0x00000001067bb759
>>> g_signal_emit_valist + 1801
>>> 14 libgobject-2.0.0.dylib 0x00000001067bcf24
>>> g_signal_emit + 356
>>>
>>>
>>> Après analyse, il s’avère que dans accueil.c la variable
>>> main_page_finished_scheduled_transactions_part n’est pas initialisée
>>> avant l’utilisation de
>>> gsb_main_page_update_finished_scheduled_transactions().
>>> du coup, j’ai ajouté un « if » avant son utilisation (accueil.c:2133) :
>>>
>>> if (main_page_finished_scheduled_transactions_part) {
>>> gtk_box_pack_start (GTK_BOX
>>> (main_page_finished_scheduled_transactions_part),
>>> hbox,
>>> FALSE,
>>> TRUE,
>>> 0);
>>> gtk_widget_show ( label);
>>>
>>> show_paddingbox (main_page_finished_scheduled_transactions_part);
>>> }
>>>
>>> Cela semble résoudre le problème.
>>> Pas sur que ce soit le meilleur fix. Qu’en pensez-vous ?
>>>
>>>
>>> Cordialement
>>> _______________________________________________
>>> devel mailing list
>>> devel at listes.grisbi.org
>>> http://listes.grisbi.org/mailman/listinfo/devel
>
>
--
A+
Pierre Biava
More information about the devel
mailing list