Hide Forgot
libreport version: 2.0.7 abrt_version: 2.0.6 backtrace_rating: 4 cmdline: /usr/libexec/e-calendar-factory comment: - no idea, crash is happening frequently judging by what logwatch is reporting, always the same segfault, but it is not associated with any particular user activity crash_function: g_type_check_instance_cast executable: /usr/libexec/e-calendar-factory kernel: 3.1.2-1.fc16.x86_64 pid: 1876 pwd: / reason: Process /usr/libexec/e-calendar-factory was killed by signal 11 (SIGSEGV) time: Sat 03 Dec 2011 10:46:11 AM NST uid: 1000 var_log_messages: Dec 3 10:46:14 CPE001a925a5df3-CM00169243ec4c abrt[9489]: Saved core dump of pid 1876 (/usr/libexec/e-calendar-factory) to /var/spool/abrt/ccpp-2011-12-03-10:46:11-1876 (53489664 bytes) backtrace: Text file, 24611 bytes build_ids: Text file, 3608 bytes dso_list: Text file, 6171 bytes maps: Text file, 37989 bytes environ: :SHELL=/bin/bash :DBUS_STARTER_ADDRESS=unix:abstract=/tmp/dbus-NqTHybHxB3,guid=737f6c29fbffb7f69e8bf4c50000002d :XDG_SESSION_COOKIE=9d5da949cd9aa6200818c38a00000068-1322848320.131592-592286965 :XDG_RUNTIME_DIR=/run/user/prower :DISPLAY=:0 :DESKTOP_SESSION=gnome :SSH_AUTH_SOCK=/tmp/keyring-I2DQwg/ssh :SESSION_MANAGER=local/unix:@/tmp/.ICE-unix/1549,unix/unix:/tmp/.ICE-unix/1549 :WINDOWPATH=1 :PATH=/usr/local/bin:/usr/bin:/bin :GNOME_DESKTOP_SESSION_ID=this-is-deprecated :GDMSESSION=gnome :XDG_VTNR=1 :USERNAME=prower :XDG_SESSION_ID=2 :GPG_AGENT_INFO=/tmp/keyring-I2DQwg/gpg:0:1 :DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-NqTHybHxB3,guid=737f6c29fbffb7f69e8bf4c50000002d :XDG_SEAT=seat0 :XAUTHORITY=/var/run/gdm/auth-for-prower-wRuQbV/database :USER=prower :DBUS_STARTER_BUS_TYPE=session :GNOME_KEYRING_PID=1543 :SHLVL=1 :PWD=/home/prower :GNOME_KEYRING_CONTROL=/tmp/keyring-I2DQwg :LANG=en_US.UTF-8 :_=/usr/bin/dbus-launch :LOGNAME=prower :HOME=/home/prower
Created attachment 541146 [details] File: dso_list
Created attachment 541147 [details] File: build_ids
Created attachment 541148 [details] File: maps
Created attachment 541149 [details] File: backtrace
Thanks for a bug report. It's closing GDBus connection and breaks for a strange reason. It can be due to memory corruption. Will it be possible to install valgrind, and run the e-calendar-factory under it, to see whether it'll discover the issue, please? You can do that with a command like this being run from a terminal at the beginning of the day: $ G_SLICE=always-malloc valgrind --num-callers=50 \ /usr/libexec/e-calendar-factory --keep-running &>log.txt only make sure no e-calendar-factory process is running before you execute it. Then run evolution and use it as usually. At the end of the day, if the factory will not stop on its own earlier, go to the terminal where you run it and press Ctrl+C, then wait for few seconds till it's closed. After that the log.txt file will contain all what the valgrind found. It may not contain any private information like emails, user names or passwords, but it's better to check before you upload it here. Note that operations with calendar can be slower with the factory being run under valgrind, it's due to all memory checking.
I don't actually use Evolution, in fact I haven't started it once since I installed F16...e-calendar-factory seems to be run the moment that I log in regardless. I'll create an account in Evolution nonetheless and run it through valgrind as requested today, hopefully that will give you some useful information. I will attach the log file as soon as possible, thank you for looking into this.
Alright...I did the following with Evolution just to make sure I had my bases covered: - set up an account (including e-mail) - added several dates to the calendar just so there would hopefully be some activity (i.e. the crash) And...nothing happened. Bugs are like that sometimes, I suppose, when someone's trying to hunt them down they hide. ;> I have the log file available from valgrind, but other than a possible memory leak it doesn't give much information. I've attached it here.
Created attachment 541550 [details] Valgrind log
Thanks for the update. The e-calendar-factory is running, because evolution-alarm-notify process is run after login, to be able to notify users about events with alarms. You are absolutely right, sometimes when one tries to catch a bug it just doesn't happen. It's pity, but it's how it is. The attached valgrind log doesn't provide any useful information, just as you said. I'm sorry, but I'm closing this for now. Maybe you'll find some time and be able to reproduce "on the background". Thanks again.
Thread 1 (Thread 0x7fe70bc9a7c0 (LWP 1876)): #0 g_type_check_instance_cast (type_instance=0x7fe6f0007550, iface_type=80) at gtype.c:3985 node = <optimized out> iface = <optimized out> is_instantiatable = <optimized out> check = <optimized out> #1 0x0000003b7c6465fe in on_object_unregistered (object=0x7fe6f0007550) at e-gdbus-cal.c:1477 idle_id = <optimized out> #2 0x0000003b758a9b57 in exported_interface_free (ei=0x1121490) at gdbusconnection.c:3719 No locals. #3 0x0000003b6ea32803 in g_hash_table_remove_all_nodes (hash_table=0x7fe6f4007700, notify=<optimized out>) at ghash.c:495 i = <optimized out> key = <optimized out> value = 0x1121490 #4 0x0000003b6ea331fa in g_hash_table_unref (hash_table=0x7fe6f4007700) at ghash.c:972 __PRETTY_FUNCTION__ = "g_hash_table_unref" #5 0x0000003b758aa6a5 in exported_object_free (eo=0x1130760) at gdbusconnection.c:3694 No locals. #6 0x0000003b6ea32803 in g_hash_table_remove_all_nodes (hash_table=0x1124000, notify=<optimized out>) at ghash.c:495 i = <optimized out> key = <optimized out> value = 0x1130760 #7 0x0000003b6ea331fa in g_hash_table_unref (hash_table=0x1124000) at ghash.c:972 __PRETTY_FUNCTION__ = "g_hash_table_unref" #8 0x0000003b758abf0d in g_dbus_connection_finalize (object=0x1125800 [GDBusConnection]) at gdbusconnection.c:535 connection = 0x1125800 [GDBusConnection] #9 0x0000003b6f61145d in g_object_unref (_object=0x1125800) at gobject.c:2746 __PRETTY_FUNCTION__ = "g_object_unref" #10 0x0000003b758a98dc in emit_closed_data_free (data=0x7fe6f8006b90) at gdbusconnection.c:1168 No locals.
*** Bug 766066 has been marked as a duplicate of this bug. ***