GNOME Bugzilla – Bug 627788
EDataCalView is never freed in a factory process
Last modified: 2013-09-13 01:10:50 UTC
Version: 2.32.x What were you doing when the application crashed? I'd been running evolution for a while. I'd looked as mail and calendar components. It was unmapped. Distribution: Slackware Slackware 12.2.0 Gnome Release: 2.31.90 2010-08-20 (GARNOME) BugBuddy Version: 2.31.3 System: Linux 2.6.35.2 #65 SMP PREEMPT Mon Aug 16 21:48:23 EDT 2010 i686 X Vendor: The X.Org Foundation X Vendor Release: 10899905 Selinux: No Accessibility: Disabled GTK+ Theme: Default Icon Theme: gnome GTK+ Modules: canberra-gtk-module, gnomesegvhandler Memory status: size: 281915392 vsize: 281915392 resident: 62169088 share: 26136576 rss: 62169088 rss_rlim: 18446744073709551615 CPU usage: start_time: 1282614073 rtime: 12181 utime: 6182 stime: 5999 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/opt/garnome-svn-2.31.90/bin/evolution' [Thread debugging using libthread_db enabled] [New Thread 0xa90ffb90 (LWP 29142)] [New Thread 0xabcffb90 (LWP 2261)] [New Thread 0xafe71b90 (LWP 6360)] [New Thread 0xb0671b90 (LWP 6359)] [New Thread 0xb0ee1b90 (LWP 6358)] [New Thread 0xb16e1b90 (LWP 6357)] 0xb5fb7171 in waitpid () from //lib/libpthread.so.0
+ Trace 223373
Thread 1 (Thread 0xb5c51b20 (LWP 6320))
Inferior 1 [process 6320] will be detached. Quit anyway? (y or n) [answered Y; input not from terminal] ---- Critical and fatal warnings logged during execution ---- ** e-utils **: Plugin "Exchange MAPI" is missing a function named e_plugin_ui_init() ** GLib-GObject **: g_object_ref: assertion `object->ref_count > 0' failed
just got similar crash on evolution 2.31.92 when changing calendar view from day to week view. (evolution:3556): GLib-GObject-CRITICAL **: g_object_ref: assertion `object->ref_count > 0' failed Program received signal SIGSEGV, Segmentation fault. 0xb675c7b0 in g_type_class_meta_marshal (closure=0x8932ae8, return_value=0x0, n_param_values=4, param_values=0x873f468, invocation_hint=0xbfffe54c, marshal_data=0x48) at gclosure.c:874 874 class = G_TYPE_INSTANCE_GET_CLASS (g_value_peek_pointer (param_values + 0), itype, GTypeClass); (gdb) bt full
+ Trace 223506
Thread 1 (Thread 0xb6067830 (LWP 3556))
*** Bug 630138 has been marked as a duplicate of this bug. ***
Do we have any consistent reproducer for this, please? I'm also wondering whether the e-addressbook-factory/e-calendar-factory is crashing when this happened. (Does bug-buddy catch such crash?)
Neither e-addressbook-factory nor e-calendar-factory crashes. There is no sure shot way to reproduce the crash. But i get mostly while doing some calendar operation. Like today i was looking for free/busy when evolution crashed.
Might this be fixed by bug #629908? I've a feeling there is a connection between these two.
I got similar crash in 2.91.2 while switching to calendar.
I also got this crash many time. There is no certain way to reproduce it but it crashes while working on calendar. Milan, I think ECalView should use lock to fix this problem.
I meant to say to protect gdbus_calview operations.
GDBus is meant to be thread safe, as far as I know. What kind of "working on calendar" are we talking about? Maybe we can investigate. Or you can try some test patch with locking, and give it some testing. Because I didn't see this myself yet. If it'll work, then it could be committed to sources for sure.
*** Bug 636487 has been marked as a duplicate of this bug. ***
^^ last dup 2.91.x ^^
I just got this crash when running under valgrind, when moving from mailer to calendar (more precisely): a) run in mailer b) go to addressbook c) go to mailer d) go to calendar These are not steps to reproduce this consistently, but it's what I did. The timing is the key here, I believe. ==17341== Invalid read of size 8 ==17341== at 0x95CF272: g_type_check_instance_cast (gtype.c:3969) ==17341== by 0x9310C57: on_signal_received (gdbusproxy.c:746) ==17341== by 0x930024A: emit_signal_instance_in_idle_cb (gdbusconnection.c:3399) ==17341== by 0x9C43D88: g_idle_dispatch (gmain.c:4532) ==17341== by 0x9C3FF35: g_main_dispatch (gmain.c:2436) ==17341== by 0x9C414C5: g_main_context_dispatch (gmain.c:3009) ==17341== by 0x9C4198B: g_main_context_iterate (gmain.c:3087) ==17341== by 0x9C42122: g_main_loop_run (gmain.c:3295) ==17341== by 0x876D59D: gtk_main (gtkmain.c:1238) ==17341== by 0x403A0C: main (main.c:734) ==17341== Address 0x9f7ace0 is 0 bytes inside a block of size 152 free'd ==17341== at 0x4A05187: free (vg_replace_malloc.c:325) ==17341== by 0x9C4993D: g_free (gmem.c:263) ==17341== by 0x9C631F4: g_slice_free1 (gslice.c:907) ==17341== by 0x95CB682: g_type_free_instance (gtype.c:1932) ==17341== by 0x95B2B96: g_object_unref (gobject.c:2727) ==17341== by 0x6C15B39: e_cal_view_finalize (e-cal-view.c:254) ==17341== by 0x95B2A97: g_object_unref (gobject.c:2714) ==17341== by 0x10ED0F6E: free_dn_queries (gnome-cal.c:1053) ==17341== by 0x10ED0FF8: update_query_async (gnome-cal.c:1074) ==17341== by 0x10ECEA4D: message_proxy (gnome-cal.c:182) ==17341== by 0x9C728DC: g_thread_pool_thread_proxy (gthreadpool.c:319) ==17341== by 0x9C711B6: g_thread_create_proxy (gthread.c:1897)
Created attachment 178247 [details] [review] eds patch for evolution-data-server; While investigating this I realized that the EDataCalView is never freed on the e-calendar-backend side, it's kept in memory forever. So this patch makes sure it's freed when the corresponding ECalView is freed (a new "dispose" DBus method on the EDataCalView was added). Apart of this I fixed also couple other things, so the backends are properly freed on the e-calendar-factory end and some related changes also done in the ECalBackend itself.
Created commit a65b1d9 in eds master (2.91.6+) I also did a little fix in evolution itself, on a new addition through the ETable (like within tasks), the evolution could crash on the source uncheck because of wrong reference counting. Created commit c9e2bbb in evo master (2.91.6+).
*** Bug 640643 has been marked as a duplicate of this bug. ***
*** Bug 649708 has been marked as a duplicate of this bug. ***