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

[nl at haplo.info]

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.

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