Discussion:
[grisbi-devel] OSX: bug et proposition de fix
Nicolas LAURENT
2017-10-08 16:55:24 UTC
Permalink
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.
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
Ludovic Rousseau
2017-10-09 16:38:34 UTC
Permalink
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().
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
n***@haplo.info
2017-10-10 06:49:42 UTC
Permalink
Bonjour,

promis, la prochaine fois, je soumettrai le fix via un pull request :)
(pour l'instant j'ai encore du mal avec github)

A+
Post by Ludovic Rousseau
Post by Nicolas LAURENT
Bonjour à tous,
Bonjour,
Post by Nicolas LAURENT
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
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
[1] pour la branche grisbi-1.0.x
et
https://github.com/grisbi/grisbi/commit/969aef4dc6b4ea2b03d255fbcf558655e875fbaf
[2] pour la branche master.
Merci
--
Dr. Ludovic Rousseau
------
[1]
https://github.com/LudovicRousseau/grisbi/commit/1ebcbc570751118a636bb337a199b3d3ba58c933
[2]
https://github.com/grisbi/grisbi/commit/969aef4dc6b4ea2b03d255fbcf558655e875fbaf
_______________________________________________
devel mailing list
http://listes.grisbi.org/mailman/listinfo/devel
Pierre Biava
2017-10-10 08:20:18 UTC
Permalink
Nicolas LAURENT a écrit le 08/10/2017 à 18:55 :

Bonjour,
Post by Nicolas LAURENT
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.
Post by Nicolas LAURENT
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().
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
http://listes.grisbi.org/mailman/listinfo/devel
--
A+

Pierre Biava
n***@haplo.info
2017-10-11 06:49:23 UTC
Permalink
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+
Post by Ludovic Rousseau
Bonjour,
Post by Nicolas LAURENT
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.
Post by Nicolas LAURENT
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().
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
http://listes.grisbi.org/mailman/listinfo/devel
Pierre Biava
2017-10-11 08:42:13 UTC
Permalink
***@haplo.info a écrit le 11/10/2017 à 08:49 :

Re,
Post by Ludovic Rousseau
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.
Post by Ludovic Rousseau
A+
Post by Ludovic Rousseau
Bonjour,
Post by Nicolas LAURENT
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.
Post by Nicolas LAURENT
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().
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
http://listes.grisbi.org/mailman/listinfo/devel
--
A+

Pierre Biava
Pierre Biava
2017-10-11 09:30:10 UTC
Permalink
Nicolas LAURENT a écrit le 08/10/2017 à 18:55 :

Re,
Post by Nicolas LAURENT
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.
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().
Ça ne devrait pas être le cas. En effet la création de la page d’accueil
se fait bien avant sa mise à jour. Mais c'est peut-être du au fait que
gtk3 devient plus strict sur la réalisation des widgets.

Ceci étant dit j'ai poussé une modification sur mon dépôt qui supprime
cette mise à jour redondante avec une autre qui se place après
l'affichage effectif de la page d'accueil. J'espère que ça résoudra le
problème.

Bonne compilation.
--
A+

Pierre Biava
Loading...