| Summary: | Reproducible SEGV in evolution-mapi syncing Calendar from Exchange 2010 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Derek Atkins <warlord> |
| Component: | evolution-mapi | Assignee: | Matthew Barnes <mbarnes> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 15 | CC: | mbarnes, mcrha |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-08-07 17:06:12 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
Thanks for a bug report and a nice backtrace. The crash happens with one event, which is recurring, and contains some changes which evolution-mapi is confused about (or it doesn't know how to operate with them and gets out of sync while parsing the blob). It will be good to get the blob value it crashes for in exchange_mapi_cal_util_bin_to_rrule(), though your backtrace shows it's optimized out. If you would be able to pass its value to the dump_bin() function in gdb, like: (gdb) print dump_bin(ba->data, ba->len, "") and paste the result here, then it'll help to investigate what broke there. Maybe the parent frame will have the value available. Oops, I just noticed, this is Fedora 15. The evolution-mapi-3.2.x in Fedora 16 has this code fully rewritten, parsing is supposed to be complete. The above comment is for "the new code doesn't seem to be so complete as expected". Trying with Fedora 16 first, with some kind of live CD or such, will be appreciated. Yes, it is F15. On F16 it does appear to load the calendar fine without crashing. It's still syncing right now, but it does appear to be working. *pause* Ah, there we go. Sync finished successfully. Any chance to backport 3.2 to F15? The only problem I am seeing in 3.2 on F16 is that Mapi calendar does not recover properly after working offline. When I come back online I get: (evolution:13553): calendar-gui-WARNING **: Default client not loaded This happens when I click on New -> Appointment with the MAPI calendar selected. (Granted, that's a completely different issue than this one, but clearly evo hasn't yet solved the offline/online mapi issues yet, even in 3.2) (In reply to comment #3) > Any chance to backport 3.2 to F15? Unfortunately not, it has some dependencies which are not easy to backport. (In reply to comment #4) > The only problem I am seeing in 3.2 on F16 is that Mapi calendar does not > recover properly after working offline. When I come back online I get: > > (evolution:13553): calendar-gui-WARNING **: Default client not loaded > > This happens when I click on New -> Appointment with the MAPI calendar > selected. (Granted, that's a completely different issue than this one, but > clearly evo hasn't yet solved the offline/online mapi issues yet, even in 3.2) Hmm, I guess it's due to the calendar taking it longer time to be loaded, the e-calendar-factory can be "stuck" on update of one calendar and waits till the other is loaded; or a bug in the code. I think, if you'll either wait for a minute, or choose a different caledanr, like the On This Computer/Personal, and then back your MAPI calendar, then it should start to work. I believe this is not related to online/offline handing in a calendar backend, because many of them do not have this implemented. Thinking of it, should I close this as current release in favour of Fedora 16 version? This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping |
Description of problem: I'm trying to sync evolution to my Exchange 2010 calendar. It fails in the same place in the sync every time (77%). I have cleared my cache to try again and it still repeats the crash every time. Version-Release number of selected component (if applicable): evolution-mapi-3.0.3-2.fc15.x86_64 evolution-3.0.3-1.fc15.x86_64 evolution-data-server-devel-3.0.3-1.fc15.x86_64 evolution-data-server-3.0.3-1.fc15.x86_64 How reproducible: 100% when used against my calendar data. I suspect there is something in my calendar data causing the crash. Steps to Reproduce: 1. clear the cache (not required) 2. start evolution, make sure you're on the calendar page 3. wait for the sync to reach 77% Actual results: The e-calendar-factory process crashes. Expected results: No data should cause the process to crash.. And the calendar should sync. Additional info: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f4d79de2700 (LWP 20863)] exchange_mapi_cal_util_bin_to_rrule (ba=<optimized out>, comp=<optimized out>, extra_detached=0x7f4d79dd99d0, recur_zone=<optimized out>) at exchange-mapi-cal-recur-utils.c:848 848 ptr += flag32; (gdb) t a a bt Thread 5 (Thread 0x7f4d7c428700 (LWP 20856)): #0 0x0000003adc8d7423 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87 #1 0x0000003ade842d24 in g_main_context_poll (n_fds=3, fds=0x7f4d74001150, priority=<optimized out>, timeout=-1, context=0x8d8a30) at gmain.c:3405 #2 g_main_context_iterate (context=0x8d8a30, block=<optimized out>, dispatch= 1, self=<optimized out>) at gmain.c:3087 #3 0x0000003ade84360d in g_main_loop_run (loop=0x8d8a10) at gmain.c:3300 #4 0x0000003ae08b4564 in gdbus_shared_thread_func (data=<optimized out>) at gdbusprivate.c:276 #5 0x0000003ade8683a6 in g_thread_create_proxy (data=0x8d8b20) at gthread.c:1955 #6 0x0000003adcc07b31 in start_thread (arg=0x7f4d7c428700) at pthread_create.c:305 #7 0x0000003adc8dfd2d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 Thread 4 (Thread 0x7f4d7b219700 (LWP 20860)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:219 #1 0x0000003adf002405 in g_cond_timed_wait_posix_impl (cond=<optimized out>, ---Type <return> to continue, or q <return> to quit--- entered_mutex=<optimized out>, abs_time=<optimized out>) at gthread-posix.c:242 #2 0x00007f4d7ca6fe5d in ?? () from /usr/lib64/evolution-data-server/calendar-backends/libecalbackendcaldav.so #3 0x0000003ade8683a6 in g_thread_create_proxy (data=0xb96e40) at gthread.c:1955 #4 0x0000003adcc07b31 in start_thread (arg=0x7f4d7b219700) at pthread_create.c:305 #5 0x0000003adc8dfd2d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 Thread 3 (Thread 0x7f4d7a5e3700 (LWP 20861)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:219 #1 0x0000003adf002405 in g_cond_timed_wait_posix_impl (cond=<optimized out>, entered_mutex=<optimized out>, abs_time=<optimized out>) at gthread-posix.c:242 #2 0x00007f4d7ca6fe5d in ?? () from /usr/lib64/evolution-data-server/calendar-backends/libecalbackendcaldav.so #3 0x0000003ade8683a6 in g_thread_create_proxy (data=0x1bc69c0) at gthread.c:1955 ---Type <return> to continue, or q <return> to quit--- #4 0x0000003adcc07b31 in start_thread (arg=0x7f4d7a5e3700) at pthread_create.c:305 #5 0x0000003adc8dfd2d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 Thread 2 (Thread 0x7f4d79de2700 (LWP 20863)): #0 exchange_mapi_cal_util_bin_to_rrule (ba=<optimized out>, comp=<optimized out>, extra_detached=0x7f4d79dd99d0, recur_zone=<optimized out>) at exchange-mapi-cal-recur-utils.c:848 #1 0x00007f4d7f3f15d4 in exchange_mapi_cal_util_mapi_props_to_comp (conn= 0x7f4d6c082000 [ExchangeMapiConnection], fid=5516961190980354049, kind=<optimized out>, mid=0x7f4d687c3fb0 "comp", properties=<optimized out>, streams=0xba1e60 = {...}, recipients= 0xba1ea0 = {...}, attachments=0xba0f90 = {...}, local_store_uri= 0x1bc7a10 "/home/warlord/.cache/evolution/calendar/mapi___datkins.3.216_;4C902EF91C000001", default_zone=0x7f4d680010c0, is_reply=0, detached_components=0x7f4d79dd99d0) at exchange-mapi-cal-utils.c:964 #2 0x00007f4d7f60cfa2 in mapi_cal_get_changes_cb (item_data=0x7f4d687c6710, data=0x8e6400) at e-cal-backend-mapi.c:452 #3 0x00007f4d7f3ebfdb in exchange_mapi_connection_fetch_items (conn= 0x7f4d6c082000 [ExchangeMapiConnection], fid=5516961190980354049, res=<optimized out>, sort_order=<optimized out>, build_props=<optimized out>, brp_data=<optimized out>, cb= ---Type <return> to continue, or q <return> to quit--- 0x7f4d7f60cb70 <mapi_cal_get_changes_cb>, data=0x8e6400, options=15, perror=0x7f4d79dd9d08) at exchange-mapi-connection.c:1877 #4 0x00007f4d7f60d5a3 in get_deltas (handle=0x8e6400) at e-cal-backend-mapi.c:804 #5 0x00007f4d7f610134 in delta_thread (data=0x8e6400) at e-cal-backend-mapi.c:1142 #6 0x0000003ade8683a6 in g_thread_create_proxy (data=0x7f4d6c00aef0) at gthread.c:1955 #7 0x0000003adcc07b31 in start_thread (arg=0x7f4d79de2700) at pthread_create.c:305 #8 0x0000003adc8dfd2d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 Thread 1 (Thread 0x7f4d85e447e0 (LWP 20855)): #0 0x0000003adc8d7423 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87 #1 0x0000003ade842d24 in g_main_context_poll (n_fds=5, fds=0x8e1550, priority=<optimized out>, timeout=-1, context=0x8a3b10) at gmain.c:3405 #2 g_main_context_iterate (context=0x8a3b10, block=<optimized out>, dispatch= 1, self=<optimized out>) at gmain.c:3087 #3 0x0000003ade84360d in g_main_loop_run (loop=0x8a3c00) at gmain.c:3300 #4 0x000000000040351f in ?? () ---Type <return> to continue, or q <return> to quit--- #5 0x0000003adc82139d in __libc_start_main (main=0x4033a0, argc=1, ubp_av= 0x7fff0abed408, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff0abed3f8) at libc-start.c:226 #6 0x00000000004035a1 in ?? () #7 0x00007fff0abed3f8 in ?? () #8 0x000000000000001c in ?? () #9 0x0000000000000001 in ?? () #10 0x00007fff0abeec13 in ?? () #11 0x0000000000000000 in ?? () (gdb) (gdb) p ptr $1 = (guint8 *) 0x7f4ddba06e08 <Address 0x7f4ddba06e08 out of bounds> (gdb) p flag32 Cannot access memory at address 0x7f4ddba06e04