Re: [grisbi-devel] OSX: bug et proposition de fix
Pierre Biava <[email protected]>
| Newsgroups | gmane.linux.grisbi.devel.french |
|---|---|
| Message-ID | <[email protected]> |
[email protected] 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 >>> [email protected] >>> http://listes.grisbi.org/mailman/listinfo/devel > > -- A+ Pierre Biava _______________________________________________ devel mailing list [email protected] http://listes.grisbi.org/mailman/listinfo/devel