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 675285 - [abrt] Crash on deleted event move
[abrt] Crash on deleted event move
Status: RESOLVED FIXED
Product: evolution-ews
Classification: Other
Component: Calendar
3.4.x
Other Linux
: Normal critical
: ---
Assigned To: Evolution EWS maintainer(s)
Evolution EWS maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2012-05-02 09:22 UTC by Milan Crha
Modified: 2012-07-27 12:01 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
ews patch (4.26 KB, patch)
2012-07-27 11:55 UTC, Milan Crha 		committed Details | Review

Description Milan Crha 2012-05-02 09:22:55 UTC 
Moving this from a downstream bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=817431

[abrt] evolution-data-server-3.4.1-2.fc17: ews_cal_modify_object_cb: Process /usr/libexec/evolution-calendar-factory was killed by signal 11 (SIGSEGV)

libreport version: 2.0.10
abrt_version:   2.0.10
backtrace_rating: 4
cmdline:        /usr/libexec/evolution-calendar-factory
comment:        I opened Evolution, and the calendar (via EWS) synced with
Exchange 2010. I created an entry in the Evolution interface. It appeared in
the Exchange calendar. I deleted the entry in the Exchange calendar via the
Outlook Web Interface. HOWEVER: the entry did NOT delete out of Evolution's
interface. In Evolution, I tried to drag the
deleted-in-Outlook-but-still-showing-in-Evolution entry to a later hour of the
day.  The calendar-factory crashed.
crash_function: ews_cal_modify_object_cb
executable:     /usr/libexec/evolution-calendar-factory
kernel:         3.3.4-1.fc17.x86_64
time:           Mon 30 Apr 2012 02:00:06 AM SAST

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

+ Trace 230163

Thread 5 (Thread 0x7f209effd700 (LWP 9476))

  • #0 __lll_unlock_wake
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S line 372
  • #1 _L_unlock_586
    from /lib64/libpthread.so.0
  • #2 __pthread_mutex_unlock_usercnt
    at pthread_mutex_unlock.c line 53
  • #3 __pthread_mutex_unlock
    at pthread_mutex_unlock.c line 298
  • #4 g_mutex_unlock
    at gthread-posix.c line 227
  • #5 g_source_attach
    at gmain.c line 927
  • #6 g_simple_async_result_complete_in_idle
    at gsimpleasyncresult.c line 809
  • #7 ews_response_cb
    at e-ews-connection.c line 524
  • #8 process_queue_item
    at soup-session-async.c line 432
  • #9 run_queue
    at soup-session-async.c line 467
  • #10 idle_run_queue
    at soup-session-async.c line 494
  • #11 g_main_dispatch
    at gmain.c line 2515
  • #12 g_main_context_dispatch
    at gmain.c line 3052
  • #13 g_main_context_iterate
    at gmain.c line 3123
  • #14 g_main_loop_run
    at gmain.c line 3317
  • #15 e_ews_soup_thread
    at e-ews-connection.c line 1049
  • #16 g_thread_proxy
    at gthread.c line 801
  • #17 start_thread
    at pthread_create.c line 309
  • #18 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 115

Thread 1 (Thread 0x7f20baf18800 (LWP 9461))

  • #0 ews_cal_modify_object_cb
    at e-cal-backend-ews.c line 1706
  • #1 g_simple_async_result_complete
    at gsimpleasyncresult.c line 767
  • #2 complete_in_idle_cb
    at gsimpleasyncresult.c line 779
  • #3 g_main_dispatch
    at gmain.c line 2515
  • #4 g_main_context_dispatch
    at gmain.c line 3052
  • #5 g_main_context_iterate
    at gmain.c line 3123
  • #6 g_main_loop_run
    at gmain.c line 3317
  • #7 e_dbus_server_run
    at e-dbus-server.c line 253
  • #8 main
    at evolution-calendar-factory.c line 149 






Comment 1


Milan Crha





          2012-07-27 10:48:16 UTC
        



Confirming, I can reproduce it too. The server returns:

 <m:UpdateItemResponse ...>
   <m:ResponseMessages>
     <m:UpdateItemResponseMessage ResponseClass="Error">
       <m:MessageText>The specified object was not found in the store.</m:MessageText>
       <m:ResponseCode>ErrorItemNotFound</m:ResponseCode>
       <m:DescriptiveLinkKey>0</m:DescriptiveLinkKey>
       <m:Items/>
     </m:UpdateItemResponseMessage>
   </m:ResponseMessages>
 </m:UpdateItemResponse>

though in the function above is error NULL, same as item_id, where dereferencing item_id leads to the crash.






Comment 2


Milan Crha





          2012-07-27 10:57:10 UTC
        



Err, I caused it with my changes from bug #670217.






Comment 3


Milan Crha





          2012-07-27 11:55:58 UTC
        



Created attachment 219733 [details] [review]
ews patch

for evolution-ews;

This was slightly tricky, because the same result parser was used for GetItems, UpdateItems, CreateItems and MoveItems requests, but only on GetItems was counted with possible error items returned from the server ('error item' is an item, which holds error information). I overlooked the multi-usage of the response parser function, which led to the crash, because the code didn't check what item type the returned item is, it expects always correct item. I didn't change this part, I changed the other callers, which are usually called for one item anyway.






Comment 4


Milan Crha





          2012-07-27 12:01:04 UTC
        



Created commit a89bd0b in ews master (3.5.5+)
Created commit 2e8e66d in ews gnome-3-4 (3.4.4+)