[evolution] segfault lors de l'ouverture du calendrier
[evolution] segfault lors de l'ouverture du calendrier
Bonjour,
Depuis que j'ai installé archlinux, evolution segfault dès l'ouverture du calendrier.
Mon architecture est amd64.
lorsque je lance :
evolution -c mail, je n'ai aucun problème avec évolution, jusq'a ce que j'utilse le calendrier, et la c'est segfault direct (pas d'affichage sur la console entre le clique sur le bouton calendrier et le segfault.
Je n'ai pas trouvé de d'option verbose ou autre sur la commande évolution.
Merci pour vos suggestions.
Depuis que j'ai installé archlinux, evolution segfault dès l'ouverture du calendrier.
Mon architecture est amd64.
lorsque je lance :
evolution -c mail, je n'ai aucun problème avec évolution, jusq'a ce que j'utilse le calendrier, et la c'est segfault direct (pas d'affichage sur la console entre le clique sur le bouton calendrier et le segfault.
Je n'ai pas trouvé de d'option verbose ou autre sur la commande évolution.
Merci pour vos suggestions.
- Desintegr
- Chu Ko Nu
- Messages : 354
- Inscription : jeu. 28 avr. 2011, 16:42
- Localisation : Orléans - France
Re: [evolution] segfault lors de l'ouverture du calendrier
Tu peux utiliser strace pour afficher les appels systèmes que fait le programme avant de planter.
Tu peux aussi essayer de recompiler avec les informations de debug pour avoir plus d'information sur le plantage : https://wiki.archlinux.org/index.php/De ... ing_Traces
Tu peux aussi essayer de recompiler avec les informations de debug pour avoir plus d'information sur le plantage : https://wiki.archlinux.org/index.php/De ... ing_Traces
Re: [evolution] segfault lors de l'ouverture du calendrier
Merci Desintegr,
J'ai lancé strace evolution et j'ai maintenant des infos suplémentaires sur le problème:
je crois comprendre qu'il y a un problème avec le fichier /etc/localtime (pourtant l'ordi est à l'heure et gnome shell n'a pas l'air de se plaindre...)
edit 1: après consutlation dudit fichier /etc/localtime, il est vrai que ce fichier est plutôt étrange, il ressemble d'avantage à un binaire qu'a un fichier de configuration...
edit 2: j'ai regardé certains des fichiers de /usr/share/zoneinfo : il ont l'air construits sur le meme modèle : ilisible
J'ai lancé strace evolution et j'ai maintenant des infos suplémentaires sur le problème:
Code : Tout sélectionner
gettimeofday({1310913607, 662540}, NULL) = 0
sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\4\1\1\210\0\0\0|\1\0\0v\0\0\0\1\1o\0\36\0\0\0/org/a11"..., 136}, {"\21\0\0\0accessible-parent\0\0\0\0\0\0\0\0\0\0\0"..., 136}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 272
gettimeofday({1310913607, 665391}, NULL) = 0
gettimeofday({1310913607, 665698}, NULL) = 0
sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\4\1\1\210\0\0\0}\1\0\0v\0\0\0\1\1o\0\36\0\0\0/org/a11"..., 136}, {"\21\0\0\0accessible-parent\0\0\0\0\0\0\0\0\0\0\0"..., 136}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 272
gettimeofday({1310913607, 665994}, NULL) = 0
gettimeofday({1310913607, 666152}, NULL) = 0
sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\4\1\1\210\0\0\0~\1\0\0v\0\0\0\1\1o\0\36\0\0\0/org/a11"..., 136}, {"\21\0\0\0accessible-parent\0\0\0\0\0\0\0\0\0\0\0"..., 136}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 272
gettimeofday({1310913607, 666353}, NULL) = 0
gettimeofday({1310913607, 666512}, NULL) = 0
sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\4\1\1\210\0\0\0\177\1\0\0v\0\0\0\1\1o\0\36\0\0\0/org/a11"..., 136}, {"\21\0\0\0accessible-parent\0\0\0\0\0\0\0\0\0\0\0"..., 136}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 272
gettimeofday({1310913607, 666753}, NULL) = 0
gettimeofday({1310913607, 666919}, NULL) = 0
sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\4\1\1\210\0\0\0\200\1\0\0v\0\0\0\1\1o\0\36\0\0\0/org/a11"..., 136}, {"\21\0\0\0accessible-parent\0\0\0\0\0\0\0\0\0\0\0"..., 136}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 272
gettimeofday({1310913607, 667121}, NULL) = 0
sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\4\1\1X\0\0\0\201\1\0\0v\0\0\0\1\1o\0\36\0\0\0/org/a11"..., 136}, {"\17\0\0\0accessible-role\0\0\0\0\0\0\0\0\0\1u\0\0"..., 88}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 224
gettimeofday({1310913607, 667424}, NULL) = 0
gettimeofday({1310913607, 667583}, NULL) = 0
sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\4\1\1\210\0\0\0\202\1\0\0v\0\0\0\1\1o\0\36\0\0\0/org/a11"..., 136}, {"\21\0\0\0accessible-parent\0\0\0\0\0\0\0\0\0\0\0"..., 136}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 272
gettimeofday({1310913607, 667788}, NULL) = 0
gettimeofday({1310913607, 667940}, NULL) = 0
sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\4\1\1\210\0\0\0\203\1\0\0v\0\0\0\1\1o\0\36\0\0\0/org/a11"..., 136}, {"\21\0\0\0accessible-parent\0\0\0\0\0\0\0\0\0\0\0"..., 136}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 272
gettimeofday({1310913607, 668140}, NULL) = 0
brk(0x2b26000) = 0x2b26000
gettimeofday({1310913607, 684141}, NULL) = 0
sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\4\1\1\210\0\0\0\204\1\0\0v\0\0\0\1\1o\0\36\0\0\0/org/a11"..., 136}, {"\21\0\0\0accessible-parent\0\0\0\0\0\0\0\0\0\0\0"..., 136}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 272
gettimeofday({1310913607, 684424}, NULL) = 0
gettimeofday({1310913607, 685357}, NULL) = 0
sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\4\1\1\210\0\0\0\205\1\0\0v\0\0\0\1\1o\0\36\0\0\0/org/a11"..., 136}, {"\21\0\0\0accessible-parent\0\0\0\0\0\0\0\0\0\0\0"..., 136}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 272
gettimeofday({1310913607, 685688}, NULL) = 0
brk(0x2b47000) = 0x2b47000
brk(0x2b46000) = 0x2b46000
gettimeofday({1310913607, 688748}, NULL) = 0
sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\4\1\1\210\0\0\0\206\1\0\0v\0\0\0\1\1o\0\36\0\0\0/org/a11"..., 136}, {"\21\0\0\0accessible-parent\0\0\0\0\0\0\0\0\0\0\0"..., 136}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 272
gettimeofday({1310913607, 689069}, NULL) = 0
gettimeofday({1310913607, 689517}, NULL) = 0
sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\4\1\1\210\0\0\0\207\1\0\0v\0\0\0\1\1o\0\36\0\0\0/org/a11"..., 136}, {"\21\0\0\0accessible-parent\0\0\0\0\0\0\0\0\0\0\0"..., 136}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 272
gettimeofday({1310913607, 689772}, NULL) = 0
gettimeofday({1310913607, 690399}, NULL) = 0
sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\4\1\1\210\0\0\0\210\1\0\0v\0\0\0\1\1o\0\36\0\0\0/org/a11"..., 136}, {"\21\0\0\0accessible-parent\0\0\0\0\0\0\0\0\0\0\0"..., 136}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 272
gettimeofday({1310913607, 690685}, NULL) = 0
gettimeofday({1310913607, 691149}, NULL) = 0
sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\4\1\1\210\0\0\0\211\1\0\0v\0\0\0\1\1o\0\36\0\0\0/org/a11"..., 136}, {"\21\0\0\0accessible-parent\0\0\0\0\0\0\0\0\0\0\0"..., 136}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 272
gettimeofday({1310913607, 691400}, NULL) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2945, ...}) = 0
open("/etc/localtime", O_RDONLY) = 37
fstat(37, {st_mode=S_IFREG|0644, st_size=2945, ...}) = 0
fstat(37, {st_mode=S_IFREG|0644, st_size=2945, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f33175c9000
read(37, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\f\0\0\0\f\0\0\0\0"..., 4096) = 2945
lseek(37, -1863, SEEK_CUR) = 1082
read(37, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\r\0\0\0\r\0\0\0\0"..., 4096) = 1863
lseek(37, 2944, SEEK_SET) = 2944
close(37) = 0
munmap(0x7f33175c9000, 4096) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2945, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2945, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2945, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2945, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2945, ...}) = 0
--- {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x50} (Segmentation fault) ---
+++ killed by SIGSEGV +++
Erreur de segmentation
edit 1: après consutlation dudit fichier /etc/localtime, il est vrai que ce fichier est plutôt étrange, il ressemble d'avantage à un binaire qu'a un fichier de configuration...
edit 2: j'ai regardé certains des fichiers de /usr/share/zoneinfo : il ont l'air construits sur le meme modèle : ilisible
- Desintegr
- Chu Ko Nu
- Messages : 354
- Inscription : jeu. 28 avr. 2011, 16:42
- Localisation : Orléans - France
Re: [evolution] segfault lors de l'ouverture du calendrier
Que renvoie la commande date (pour vérifier si le système utilise bien le bon fuseau) ?
Un peu étrange qu'il essaye de récupérer des infos sur /etc/localtime 5 fois de suite avant de planter. Si le fichier est identique à l'un des fichiers de /usr/share/zoneinfo, c'est qu'il est correct.
Cependant, ça ne dit pas grand chose sur la cause du plantage.
Il reste toutefois la possibilité de recompiler Evolution avec les informations de debug (voir post précédent).
La commande dmesg peut également indiquer dans quelle bibliothèque ou exécutable a planté le programme.
Un peu étrange qu'il essaye de récupérer des infos sur /etc/localtime 5 fois de suite avant de planter. Si le fichier est identique à l'un des fichiers de /usr/share/zoneinfo, c'est qu'il est correct.
Cependant, ça ne dit pas grand chose sur la cause du plantage.
Il reste toutefois la possibilité de recompiler Evolution avec les informations de debug (voir post précédent).
La commande dmesg peut également indiquer dans quelle bibliothèque ou exécutable a planté le programme.
Re: [evolution] segfault lors de l'ouverture du calendrier
Code : Tout sélectionner
[yohann@mao etc]$ date
dim. juil. 17 18:09:46 CEST 2011
Code : Tout sélectionner
[ 3100.175691] evolution[1438]: segfault at 50 ip 00007ff19733ceb5 sp 00007fff9de821d0 error 4 in libetable.so.0.0.0[7ff1972ce000+8f000]
[ 7688.465076] evolution[2005]: segfault at 50 ip 00007f972d391eb5 sp 00007fffbb1b7a40 error 4 in libetable.so.0.0.0[7f972d323000+8f000]
[ 7773.101622] evolution[2011]: segfault at 50 ip 00007f6d61dbceb5 sp 00007fff9b39a520 error 4 in libetable.so.0.0.0[7f6d61d4e000+8f000]
[ 9739.299286] gnome-settings-[1309]: segfault at 7fe057bb5210 ip 00007fe057bb5210 sp 00007fff2af98e18 error 14
[ 9884.071022] gnome-settings-[2362]: segfault at 7fefb7b2b210 ip 00007fefb7b2b210 sp 00007fffb3030a68 error 14 in libdbus-1.so.3.5.7[7fefb819c000+42000]
[19158.563978] evolution[5920]: segfault at 50 ip 00007f18ba99feb5 sp 00007fff11c4d850 error 4 in libetable.so.0.0.0[7f18ba931000+8f000]
qaund au fichier localtime, je penche plus pour une coïncidence car si je fait strace evolution -c mail puis que je lance le calendrier depuis l'interface de evolution, l'accès à se fichier ne précède pas immédiatement le segfault.
Je vais donc me documenter un peu sur cette libetable en attendant mieux
edit: la recherche sur le problème avec ces nouveau mots clé me renvoie vers https://bbs.archlinux.org/viewtopic.php?pid=928634
ce qui n'est pas très aidant, mais au moins je ne suis pas seul dans ce cas.
- Desintegr
- Chu Ko Nu
- Messages : 354
- Inscription : jeu. 28 avr. 2011, 16:42
- Localisation : Orléans - France
Re: [evolution] segfault lors de l'ouverture du calendrier
Un post sur un problème similaire au tien : https://bbs.archlinux.org/viewtopic.php?id=117004
Crash sur l'accès au calendrier et la libetable.so en cause.
Le problème s'est résolu tout seul avec les mises à jour.
Ton système est bien à jour ?
Un autre bug similaire (mais sur une ancienne version) : https://bugs.launchpad.net/ubuntu/+sour ... bug/716433
Crash sur l'accès au calendrier et la libetable.so en cause.
Le problème s'est résolu tout seul avec les mises à jour.
Ton système est bien à jour ?
Un autre bug similaire (mais sur une ancienne version) : https://bugs.launchpad.net/ubuntu/+sour ... bug/716433
Re: [evolution] segfault lors de l'ouverture du calendrier
oui mon systeme est à jour, en fait c'est marrant, c'est le meme fil de discussion que celui que j'indique, mais avec un autre id...
le fait est que apparement ces personnes sont en [testing], donc, il me faut attendre que evolution evolue...
ou alors il faut que je vois comment on peut ajouter un paquet testing dans une archlinux stable en attendant que evolution testing actuel passe en stable.
edit: j'ai toujours trouvé comment mettre un seul paquet en testing, mais j'ai ajouté le dépot testing avant de faire un mise a jour pour voir si des paquets concernant evolution était proposés: aucun, j'imagine que le sujet surlequel on est tombé concerne une architecture i686
le fait est que apparement ces personnes sont en [testing], donc, il me faut attendre que evolution evolue...
ou alors il faut que je vois comment on peut ajouter un paquet testing dans une archlinux stable en attendant que evolution testing actuel passe en stable.
edit: j'ai toujours trouvé comment mettre un seul paquet en testing, mais j'ai ajouté le dépot testing avant de faire un mise a jour pour voir si des paquets concernant evolution était proposés: aucun, j'imagine que le sujet surlequel on est tombé concerne une architecture i686
- FoolEcho
- Maître du Kyudo
- Messages : 10711
- Inscription : dim. 15 août 2010, 11:48
- Localisation : Basse-Normandie
Re: [evolution] segfault lors de l'ouverture du calendrier
Décommente testing dans /etc/pacman.conf, puis pacman -Syy, et installe evolution. Enfin commente testing et à nouveau pacman -Syy pour repasser en stable (tu auras juste un message d'avertissement sur les mises à jour comme quoi ta version d'evolution est plus récente que celle du dépôt).yohann a écrit :ou alors il faut que je vois comment on peut ajouter un paquet testing dans une archlinux stable en attendant que evolution testing actuel passe en stable
«The following statement is not true. The previous statement is true.» 

Re: [evolution] segfault lors de l'ouverture du calendrier
ah ben oui c'est simple en fait 
malheureusement comme expliqué dans mon edit au dessus, pas de nouveau evolution dans testing.

malheureusement comme expliqué dans mon edit au dessus, pas de nouveau evolution dans testing.