[grisbi-devel] OSX: bug et proposition de fix

[Ludovic Rousseau]

Le 8 octobre 2017 à 18:55, Nicolas LAURENT <nl at haplo.info> a écrit :

> Bonjour à tous,
>

Bonjour,


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

J'ai essayé de tracer l'arbre d'appel à la main mais c'est vite complexe.
L'interface graphique n'est pas construite depuis un seul endroit.

J'ai réutilisé ton patch dans
https://github.com/LudovicRousseau/grisbi/commit/1ebcbc570751118a636bb337a199b3d3ba58c933
pour la branche grisbi-1.0.x
et
https://github.com/grisbi/grisbi/commit/969aef4dc6b4ea2b03d255fbcf558655e875fbaf
pour la branche master.

Merci

-- 
 Dr. Ludovic Rousseau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listes.grisbi.org/pipermail/devel/attachments/20171009/24ba2894/attachment.html>