After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 725295 - [abrt] Crash in e_cal_backend_remove_view()
[abrt] Crash in e_cal_backend_remove_view()
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: Calendar
3.11.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2014-02-27 09:11 UTC by Milan Crha
Modified: 2018-03-13 17:15 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Milan Crha 2014-02-27 09:11:18 UTC 
Moving this from a downstream bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1070438

Description of problem:
Happened on boot of current Rawhide.

Version-Release number of selected component:
evolution-data-server-3.11.90-1.fc21

Additional info:
reporter:       libreport-2.1.12
backtrace_rating: 4
cmdline:        /usr/libexec/evolution-calendar-factory
crash_function: e_cal_backend_remove_view
executable:     /usr/libexec/evolution-calendar-factory
kernel:         3.14.0-0.rc4.git0.2.fc21.x86_64

Core was generated by `/usr/libexec/evolution-calendar-factory'.
Program terminated with signal SIGSEGV, Segmentation fault.

+ Trace 233241

Thread 1 (Thread 0x7f3fdb000880 (LWP 2698))

  • #0 e_cal_backend_remove_view
    at e-cal-backend.c line 1444
  • #1 impl_DataCalView_dispose
    at e-data-cal-view.c line 267
  • #2 ffi_call_unix64
    at ../src/x86/unix64.S line 76
  • #3 ffi_call
    at ../src/x86/ffi64.c line 522
  • #4 g_cclosure_marshal_generic
    at gclosure.c line 1445
  • #5 g_closure_invoke
    at gclosure.c line 768
  • #6 signal_emit_unlocked_R
    at gsignal.c line 3551
  • #7 g_signal_emit_valist
    at gsignal.c line 3317
  • #8 g_signal_emit
    at gsignal.c line 3363
  • #9 e_gdbus_stub_handle_method_call
    at e-gdbus-templates.c line 678
  • #10 call_in_idle_cb
    at gdbusconnection.c line 4875
  • #11 g_main_dispatch
    at gmain.c line 3066
  • #12 g_main_context_dispatch
    at gmain.c line 3641
  • #13 g_main_context_iterate
    at gmain.c line 3712
  • #14 g_main_loop_run
    at gmain.c line 3906
  • #15 dbus_server_run_server
    at e-dbus-server.c line 230
  • #16 ffi_call_unix64
    at ../src/x86/unix64.S line 76
  • #17 ffi_call
    at ../src/x86/ffi64.c line 522
  • #18 g_cclosure_marshal_generic_va
    at gclosure.c line 1541
  • #19 _g_closure_invoke_va
    at gclosure.c line 831
  • #20 g_signal_emit_valist
    at gsignal.c line 3215
  • #21 g_signal_emit
    at gsignal.c line 3363
  • #22 e_dbus_server_run
    at e-dbus-server.c line 419
  • #23 main
    at evolution-calendar-factory.c line 135 






Comment 1


Adam Williamson





          2014-03-26 03:02:12 UTC
        



Just hit this again with evolution-data-server-3.11.92-1.fc21.x86_64 . Seems like the Evolution Collective gets into a state where I can't launch Evo itself successfully, if I try and run it from a console it just seems to hang. Then when I run killev, this crash happens after a while. After that I can re-launch Evo successfully.






Comment 2


Milan Crha





          2014-03-26 07:15:23 UTC
        



I cannot speak for the crash itself, but maybe the hang is related to bug #726060, which is accidentally "active" right now. Though it would be good to get a backtrace of hung evolution, together with a backtrace of evolution-source-registry process from the same time, to see whether it's the same/similar issue as in bug #726060.






Comment 3


Milan Crha





          2018-03-13 17:15:57 UTC
        



I managed to reproduce this accidentally with the current development version (after 3.28.0 release). The problem exhibited when I disabled my EWS account, which had also calendars and tasks. One of the calendars had been disposing one of the views just like in the backtrace above. The trick was that the view hold the last reference on the backtrace and when it had been freeing itself, it also wanted to free the reference, which led to an attampt of clearing locked mutex, due to the backend being in e_cal_backend_remove_view() which held that view mutex. I added another references to the backend on places where this could strike both for the calendar and for the book.

Created commit cd9ec8ea2 in eds master (3.29.1+)
Created commit 178cb100d in eds gnome-3-28 (3.28.1+)