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 704220 - Incorrect runtime check in e_data_cal_respond_send_objects()
Incorrect runtime check in e_data_cal_respond_send_objects()
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Calendar
3.10.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
: 702749 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-07-15 02:06 UTC by Fabiano Fidêncio
Modified: 2013-09-21 13:35 UTC
See Also:
GNOME target: ---
GNOME version: 3.7/3.8

Attachments
eds patch (6.69 KB, patch)
2013-07-16 07:01 UTC, Milan Crha 		committed Details | Review

Description Fabiano Fidêncio 2013-07-15 02:06:25 UTC 
Steps to reproduce:
- Create a meeting with attendees using your Google Calendar
- In the Calendar view, drag the meeting to another cell
- Click yes to send the change notification for the invitees
- Boom, evolution is stuck

Milan, Matthew, what kind of information do you need?
Comment 1 Matthew Barnes 2013-07-15 02:29:20 UTC 
If you mean stuck as in the UI is frozen, then we need a GDB backtrace of Evolution ("thread apply all backtrace") with particular interest in Thread 1.

A backtrace on the evolution-calendar-factory process wouldn't hurt either, just to see whether it's gone braindead.  But even if it has, the UI should never be blocked.

My bet's on the itip-formatter module.
Comment 2 Milan Crha 2013-07-15 05:55:57 UTC 
I agree with Matthew, backtrace of the evolution and the calendar factory will show what it does. The itip-formatter is out of question, if I understood Fabiano's steps right, because it's only used in the Mail view, not in the Calendar view.
Comment 3 Fabiano Fidêncio 2013-07-15 08:34:10 UTC 
Evolution:

+ Trace 232239

Thread 1 (Thread 0x7ffff6572a00 (LWP 21707))

  • #0 poll
    from /lib64/libc.so.6
  • #1 g_main_context_iterate.isra.22
    from /lib64/libglib-2.0.so.0
  • #2 g_main_loop_run
    from /lib64/libglib-2.0.so.0
  • #3 g_dbus_connection_send_message_with_reply_sync
    from /lib64/libgio-2.0.so.0
  • #4 g_dbus_connection_call_sync_internal
    from /lib64/libgio-2.0.so.0
  • #5 g_dbus_proxy_call_sync_internal
    from /lib64/libgio-2.0.so.0
  • #6 g_dbus_proxy_call_sync
    from /lib64/libgio-2.0.so.0
  • #7 e_dbus_calendar_call_send_objects_sync
    at e-dbus-calendar.c line 2940
  • #8 e_cal_client_send_objects_sync
    at e-cal-client.c line 5740
  • #9 comp_server_send
    at itip-utils.c line 1136
  • #10 itip_send_comp
    at itip-utils.c line 1719
  • #11 e_calendar_view_modify_and_send
    at e-calendar-view.c line 1819
  • #12 e_day_view_on_top_canvas_drag_data_received
    at e-day-view.c line 8498
  • #13 _gtk_marshal_VOID__OBJECT_INT_INT_BOXED_UINT_UINT
    from /lib64/libgtk-3.so.0
  • #14 g_closure_invoke
    from /lib64/libgobject-2.0.so.0
  • #15 signal_emit_unlocked_R
    from /lib64/libgobject-2.0.so.0
  • #16 g_signal_emit_valist
    from /lib64/libgobject-2.0.so.0
  • #17 g_signal_emit_by_name
    from /lib64/libgobject-2.0.so.0
  • #18 gtk_drag_selection_received
    from /lib64/libgtk-3.so.0
  • #19 g_closure_invoke
    from /lib64/libgobject-2.0.so.0
  • #20 signal_emit_unlocked_R
    from /lib64/libgobject-2.0.so.0
  • #21 g_signal_emit_valist
    from /lib64/libgobject-2.0.so.0
  • #22 g_signal_emit_by_name
    from /lib64/libgobject-2.0.so.0
  • #23 gtk_selection_retrieval_report
    from /lib64/libgtk-3.so.0
  • #24 gtk_selection_convert
    from /lib64/libgtk-3.so.0
  • #25 gtk_drag_dest_drop
    from /lib64/libgtk-3.so.0
  • #26 _gtk_drag_dest_handle_event
    from /lib64/libgtk-3.so.0
  • #27 gtk_main_do_event
    from /lib64/libgtk-3.so.0
  • #28 gdk_event_source_dispatch
    from /lib64/libgdk-3.so.0
  • #29 g_main_context_dispatch
    from /lib64/libglib-2.0.so.0
  • #30 g_main_context_iterate.isra.22
    from /lib64/libglib-2.0.so.0
  • #31 g_main_loop_run
    from /lib64/libglib-2.0.so.0
  • #32 gtk_main
    from /lib64/libgtk-3.so.0
  • #33 main
    at main.c line 683 






Comment 4


Fabiano Fidêncio





          2013-07-15 08:35:22 UTC
        



Calendar Factory:





+
Trace
    232240






Thread 1
          (Thread 0x7ffff72599c0 (LWP 21694))


    

  • 
#0
poll

    
                from
                /lib64/libc.so.6

    

    • 

  • 
#1
g_main_context_iterate.isra.22

    
                from
                /lib64/libglib-2.0.so.0

    

    • 

  • 
#2
g_main_loop_run

    
                from
                /lib64/libglib-2.0.so.0

    

    • 

  • 
#3
dbus_server_run_server

    
                at e-dbus-server.c
                  line
                  222

    

    • 

  • 
#4
ffi_call_unix64

    
                from
                /lib64/libffi.so.6

    

    • 

  • 
#5
ffi_call

    
                from
                /lib64/libffi.so.6

    

    • 

  • 
#6
g_cclosure_marshal_generic_va

    
                from
                /lib64/libgobject-2.0.so.0

    

    • 

  • 
#7
_g_closure_invoke_va

    
                from
                /lib64/libgobject-2.0.so.0

    

    • 

  • 
#8
g_signal_emit_valist

    
                from
                /lib64/libgobject-2.0.so.0

    

    • 

  • 
#9
g_signal_emit

    
                from
                /lib64/libgobject-2.0.so.0

    

    • 

  • 
#10
e_dbus_server_run

    
                at e-dbus-server.c
                  line
                  411

    

    • 

  • 
#11
main

    
                at evolution-calendar-factory.c
                  line
                  140

    

    • 













Comment 5


Fabiano Fidêncio





          2013-07-15 08:36:03 UTC
        



And also this critical being printed:
(evolution-calendar-factory:21694): libedata-cal-CRITICAL **: e_data_cal_respond_send_objects: assertion `component != NULL' failed






Comment 6


Milan Crha





          2013-07-15 12:42:59 UTC
        



(In reply to comment #5)
> And also this critical being printed:
> (evolution-calendar-factory:21694): libedata-cal-CRITICAL **:
> e_data_cal_respond_send_objects: assertion `component != NULL' failed

This is the reason. The function which would notify about the result failed with a runtime check, which makes the client side (evolution) wait for a response until a DBus timeout is reached. Fix this warning and the other things should be fixed as well.






Comment 7


Milan Crha





          2013-07-16 06:08:52 UTC
        



I'll fix this, I see Matthew broke it with his changes in EDataCal, specifically the sendObjects function does not return a single component, but a vCalendar, which the ECalComponent cannot hold, thus the added runtime check for component != NULL fails. Interestingly, the doc says multiple times that the returned component should be unreffed, but this is not done in places where result of e_cal_backend_send_objects_finish() is received (not counting the _sync variant of the function). The 3.8.x is safe, with this regard.






Comment 8


Milan Crha





          2013-07-16 07:01:47 UTC
        



Created attachment 249256 [details] [review]
eds patch

for evolution-data-server;

As expected, I changed API for e_cal_backend_send_objects_sync() and e_cal_backend_send_objects_finish(), which makes the meeting scheduling work again.






Comment 9


Milan Crha





          2013-07-16 07:02:37 UTC
        



Created commit 9da1873 in eds master (3.9.5+)






Comment 10


Milan Crha





          2013-07-16 10:08:12 UTC
        



Follow-up commit f9ee147, for e_cal_backend_get_object/_list(). (3.9.5+)






Comment 11


Milan Crha





          2013-08-09 12:06:07 UTC
        



*** Bug 702749 has been marked as a duplicate of this bug. ***