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 698342 - [abrt] Crash under e-cal-client.c:signal_closure_free
[abrt] Crash under e-cal-client.c:signal_closure_free
Status: RESOLVED INCOMPLETE
Product: evolution-data-server
Classification: Platform
Component: Mailer
3.8.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2013-04-19 06:16 UTC by Milan Crha
Modified: 2015-11-19 07:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Milan Crha 2013-04-19 06:16:53 UTC 
Moving this from a downstream bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=953439

Version-Release number of selected component:
evolution-3.8.0-1.fc19

Additional info:
backtrace_rating: 4
cmdline:        /usr/libexec/evolution/3.8/evolution-alarm-notify
crash_function: g_weak_ref_set
executable:     /usr/libexec/evolution/3.8/evolution-alarm-notify
kernel:         3.9.0-0.rc6.git2.3.fc19.x86_64

Core was generated by `/usr/libexec/evolution/3.8/evolution-alarm-notify'.
Program terminated with signal 6, Aborted.

+ Trace 231815

Thread 1 (Thread 0x7f9c56b4fa40 (LWP 2212))

  • #0 __GI_raise
    at ../nptl/sysdeps/unix/sysv/linux/raise.c line 56
  • #1 __GI_abort
    at abort.c line 90
  • #2 g_assertion_message
    at gtestutils.c line 1912
  • #3 g_assertion_message_expr
    at gtestutils.c line 1923
  • #4 g_weak_ref_set
    at gobject.c line 4127
  • #5 signal_closure_free
    at e-cal-client.c line 182
  • #6 g_source_callback_unref
    at gmain.c line 1541
  • #7 g_source_destroy_internal
    at gmain.c line 1200
  • #8 g_main_dispatch
    at gmain.c line 3078
  • #9 g_main_context_dispatch
    at gmain.c line 3630
  • #10 g_main_context_iterate
    at gmain.c line 3701
  • #11 g_main_context_iteration
    at gmain.c line 3762
  • #12 g_application_run
    at gapplication.c line 1623
  • #13 main
    at notify-main.c line 117 






Comment 1


Milan Crha





          2013-08-15 16:42:21 UTC
        



I get the same crash consistently in calendar factory with the below backtrace. I:
a) delete my ~/local/cache/evolution/calendar
b) start the calendar factory
c) start: evolution -c mail
d) open a meeting invitation, but close it in few seconds
e) close evolution

Wait few seconds till the factory finally realizes I cancelled the open of all (but those in alarm notification) calendars and it crashes, well, 3-4 out of 5 tries. The trick seems to be to have large CalDAV calendar, which is slower in updating.

There are these critical warnings on console, just before the crash:

(evolution-calendar-factory:6485): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed

(evolution-calendar-factory:6485): GLib-GObject-WARNING **: instance of invalid non-instantiatable type `<invalid>'

(evolution-calendar-factory:6485): GLib-GObject-CRITICAL **: g_signal_emit_by_name: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed

(evolution-calendar-factory:6485): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed

**
GLib-GObject:ERROR:gobject.c:4127:g_weak_ref_set: assertion failed: (weak_locations != NULL)

The 'signal_closure' was created in a dedicated thread, but was going to be freed in the main thread. I see the associated CalDAV backend was freed (including finalize) before the signal_closure_free() was called. Maybe this is a fallout of the critical warnings, these are shown after the finalize of the backend. Maybe not.





+
Trace
    232385






Thread 1
          (Thread 0x7f0a903699c0 (LWP 6485))


    

  • 
#0
waitpid

    
                from
                /lib64/libpthread.so.0

    

    • 

  • 
#1
g_spawn_sync

    
                at gspawn.c
                  line
                  402

    

    • 

  • 
#2
g_spawn_command_line_sync

    
                at gspawn.c
                  line
                  731

    

    • 

  • 
#3
run_bug_buddy

    
                at gnome-segvhanlder.c
                  line
                  240

    

    • 

  • 
#4
bugbuddy_segv_handle

    
                at gnome-segvhanlder.c
                  line
                  191

    

    • 

  • 
#5
<signal handler called>

    • 

  • 
#6
raise

    
                from
                /lib64/libc.so.6

    

    • 

  • 
#7
abort

    
                from
                /lib64/libc.so.6

    

    • 

  • 
#8
g_assertion_message

    
                at gtestutils.c
                  line
                  1912

    

    • 

  • 
#9
g_assertion_message_expr

    
                at gtestutils.c
                  line
                  1923

    

    • 

  • 
#10
g_weak_ref_set

    
                at gobject.c
                  line
                  4127

    

    • 

  • 
#11
signal_closure_free

    
                at e-cal-backend.c
                  line
                  172

    

    • 

  • 
#12
g_source_callback_unref

    
                at gmain.c
                  line
                  1541

    

    • 

  • 
#13
g_source_destroy_internal

    
                at gmain.c
                  line
                  1200

    

    • 

  • 
#14
g_main_dispatch

    
                at gmain.c
                  line
                  3078

    

    • 

  • 
#15
g_main_context_dispatch

    
                at gmain.c
                  line
                  3630

    

    • 

  • 
#16
g_main_context_iterate

    
                at gmain.c
                  line
                  3701

    

    • 

  • 
#17
g_main_loop_run

    
                at gmain.c
                  line
                  3895

    

    • 

  • 
#18
dbus_server_run_server

    
                at e-dbus-server.c
                  line
                  222

    

    • 

  • 
#19
ffi_call_unix64

    
                from
                /lib64/libffi.so.6

    

    • 

  • 
#20
ffi_call

    
                from
                /lib64/libffi.so.6

    

    • 

  • 
#21
g_cclosure_marshal_generic_va

    
                at gclosure.c
                  line
                  1550

    

    • 

  • 
#22
_g_closure_invoke_va

    
                at gclosure.c
                  line
                  840

    

    • 

  • 
#23
g_signal_emit_valist

    
                at gsignal.c
                  line
                  3234

    

    • 

  • 
#24
g_signal_emit

    
                at gsignal.c
                  line
                  3384

    

    • 

  • 
#25
e_dbus_server_run

    
                at e-dbus-server.c
                  line
                  411

    

    • 

  • 
#26
main

    
                at evolution-calendar-factory.c
                  line
                  140

    

    • 













Comment 2


Matthew Barnes





          2013-08-15 17:33:21 UTC
        



I'd like to see backtraces for the warnings, or at least the first one.






Comment 3


Milan Crha





          2013-08-15 20:02:59 UTC
        



Yeah, I thought so, and I managed to get the first one, it's at:




+
Trace
    232386






Thread 1
          (Thread 0x7ffff6e119c0 (LWP 8753))


    

  • 
#0
g_logv

    • 

  • 
#1
g_log

    
                at gmessages.c
                  line
                  1010

    

    • 

  • 
#2
g_type_check_instance

    
                at gtype.c
                  line
                  4118

    

    • 

  • 
#3
g_signal_emit_by_name

    
                at gsignal.c
                  line
                  3410

    

    • 

  • 
#4
cal_backend_emit_timezone_added_idle_cb

    
                at e-cal-backend.c
                  line
                  429

    

    • 

  • 
#5
g_main_dispatch

    
                at gmain.c
                  line
                  3054

    

    • 

  • 
#6
g_main_context_dispatch

    
                at gmain.c
                  line
                  3630

    

    • 

  • 
#7
g_main_context_iterate

    
                at gmain.c
                  line
                  3701

    

    • 

  • 
#8
g_main_loop_run

    
                at gmain.c
                  line
                  3895

    

    • 

  • 
#9
dbus_server_run_server

    
                at e-dbus-server.c
                  line
                  222

    

    • 

  • 
#10
ffi_call_unix64

    
                from
                /lib64/libffi.so.6

    

    • 

  • 
#11
ffi_call

    
                from
                /lib64/libffi.so.6

    

    • 

  • 
#12
g_cclosure_marshal_generic_va

    
                at gclosure.c
                  line
                  1550

    

    • 

  • 
#13
_g_closure_invoke_va

    
                at gclosure.c
                  line
                  840

    

    • 

  • 
#14
g_signal_emit_valist

    
                at gsignal.c
                  line
                  3234

    

    • 

  • 
#15
g_signal_emit

    
                at gsignal.c
                  line
                  3384

    

    • 

  • 
#16
e_dbus_server_run

    
                at e-dbus-server.c
                  line
                  411

    

    • 

  • 
#17
main

    
                at evolution-calendar-factory.c
                  line
                  140

    

    • 













Comment 4


Matthew Barnes





          2013-08-15 20:44:24 UTC
        



Hmm, I can't explain that.

The g_weak_ref_get() call should have returned NULL if the backend were already finalized.  Some kind of corruption going on here, looks like.

Valgrind might help track this down.






Comment 5


Milan Crha





          2014-06-06 14:13:32 UTC
        



Probably unrelated, but I committed a change as suggested by desrt, to use g_weak_Ref_init/_clear() on structure-allocated GWekRef-s, the same was as it is done for GMutex and other similar structures. That is with commit 685c5cd on master (3.13.3+) and commit d6255ef evolution-data-server-3-12 (3.12.3+).






Comment 6


Milan Crha





          2015-11-19 07:29:41 UTC
        



No duplicate for a long time, I'm closing this.