| Summary: | [abrt] evolution-data-server-3.2.2-1.fc16: g_type_check_instance_cast: Process /usr/libexec/e-calendar-factory was killed by signal 11 (SIGSEGV) | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | blue_t_fox | ||||||||||||
| Component: | evolution-data-server | Assignee: | Matthew Barnes <mbarnes> | ||||||||||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||||
| Priority: | unspecified | ||||||||||||||
| Version: | 16 | CC: | mbarnes, mcrha, mikeg2004 | ||||||||||||
| Target Milestone: | --- | ||||||||||||||
| Target Release: | --- | ||||||||||||||
| Hardware: | x86_64 | ||||||||||||||
| OS: | Unspecified | ||||||||||||||
| Whiteboard: | abrt_hash:0419f9abefc6f5bf4b0800d65690842ad14ec404 | ||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||
| Clone Of: | Environment: | ||||||||||||||
| Last Closed: | 2011-12-07 08:58:39 UTC | Type: | --- | ||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||
| Documentation: | --- | CRM: | |||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
blue_t_fox
2011-12-06 02:51:11 UTC
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. *** |