Bug 919889 - gnome-contacts-search-provider process eats all the CPU
Summary: gnome-contacts-search-provider process eats all the CPU
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-contacts
Version: 27
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Elad Alfassa
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-03-10 17:11 UTC by Ole Guldberg
Modified: 2020-03-26 11:05 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-30 17:41:55 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 747929 0 None None None 2016-07-22 21:31:59 UTC

Description Ole Guldberg 2013-03-10 17:11:45 UTC
Description of problem:

After logging into GNOME-Shell the system gets sluggish because the process gnome-contacts-search-provider get almost 100% of the CPU

Version-Release number of selected component (if applicable):
gnome-contacts-3.6.2-1.fc18.i686


How reproducible:

This problem happens everytime I login.

Steps to Reproduce:
1. Login
2. The process starts to eat resouces

Additional info:

I have 4 google accounts registered with "online-accounts"

Comment 1 Ole Guldberg 2013-03-10 17:40:42 UTC
A workaround this bug seems to be at disable (switch off) "Contacts" for the online-accounts.

Comment 2 Ole Guldberg 2013-03-10 17:43:30 UTC
(In reply to comment #1)
> A workaround this bug seems to be at disable (switch off) "Contacts" for the
> online-accounts.

And... no, that doesnt work ...

Comment 3 Ole Guldberg 2013-03-10 19:00:54 UTC
Removing the accounts from "online-accounts" seems to help though.

Comment 4 Brandon 2013-03-23 01:53:15 UTC
I have a similar issue, not sure if its the same one. For me it doesn't eat cpu when I login, it only does it when I'm actively searching the shell. The search is very laggy and chews cpu, the animations lag very noticeably if I search quickly. But if I remove the account from online accounts the shell search is totally smooth again. This is on pretty decent hardware too (i5-3210m, 8gbram, 7200rpm hybrid hdd)

Comment 5 Fedora End Of Life 2013-12-21 12:02:36 UTC
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is 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  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

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.

Comment 6 Fedora End Of Life 2014-02-05 19:50:09 UTC
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 7 benjamin.esquivel 2015-07-02 19:50:57 UTC
I suggest re-opening this bug since it is showing up in F22 as well.

Comment 8 David Woodhouse 2015-07-06 15:42:34 UTC
Please attach to it with gdb and show a backtrace when it's doing this.

Comment 9 Jacob Keller 2015-07-10 22:19:29 UTC
I'll try to do this next time I see it. The main problem I have is that my entire gnome shell freezes, and I can't switch to console. SSH logins via another machine still work but are very slow. If I get this again I'll try to attach via gbd and see what it is up to.

Comment 10 benjamin.esquivel 2015-07-13 19:38:07 UTC
After a couple of updates on F22, this bug has not shown his face again.

Comment 11 Jacob Keller 2015-07-13 22:18:15 UTC
I got this same problem again. I was able to attach via gdb and print a backtrace. I don't have debug symbols installed but hopefully this is still useful.

The process consumed something like 80% of my system memory, which I have something around 6GB or so. Top didn't say it was consuming all my CPU, but the entire gnome shell lagged and was 100% un-usable. I had to SSH from a separate machine, and the ssh login took several minutes to complete. So something is hogging all my system resources when this occurs.

#0  0x00007fb88579c4d6 in g_ascii_strcasecmp () at /lib64/libglib-2.0.so.0
#1  0x00007fb88dae4408 in e_vcard_get_attribute () at /lib64/libebook-contacts-1.2.so.1
#2  0x00007fb88dadf61f in e_contact_get () at /lib64/libebook-contacts-1.2.so.1
#3  0x00007fb88ec7bfdd in _edsf_persona_update_groups () at /lib64/libfolks-eds.so.25
#4  0x00007fb88ec7c860 in edsf_persona_real_get_is_favourite () at /lib64/libfolks-eds.so.25
#5  0x00007fb88ea1731b in ___lambda23__folks_individual_single_valued_property_setter () at /lib64/libfolks.so.25
#6  0x00007fb88ea1c4b1 in _folks_individual_update_single_valued_property () at /lib64/libfolks.so.25
#7  0x00007fb88ea1ceba in _folks_individual_update_is_favourite () at /lib64/libfolks.so.25
#8  0x00007fb88ea23874 in _folks_individual_set_personas () at /lib64/libfolks.so.25
#9  0x00007fb88ea24400 in folks_individual_set_personas () at /lib64/libfolks.so.25
#10 0x00007fb885a826bd in g_object_new_internal () at /lib64/libgobject-2.0.so.0
#11 0x00007fb885a83f45 in g_object_new_valist () at /lib64/libgobject-2.0.so.0
#12 0x00007fb885a842b1 in g_object_new () at /lib64/libgobject-2.0.so.0
#13 0x00007fb88ea22534 in folks_individual_construct () at /lib64/libfolks.so.25
#14 0x00007fb88ea280af in _folks_individual_aggregator_add_personas () at /lib64/libfolks.so.25
#15 0x00007fb88ea29fb2 in _folks_individual_aggregator_personas_changed_cb.isra.10 () at /lib64/libfolks.so.25
#16 0x00007fb88ea32a7f in g_cclosure_user_marshal_VOID__OBJECT_OBJECT_STRING_OBJECT_ENUM () at /lib64/libfolks.so.25
#17 0x00007fb885a7ccd5 in g_closure_invoke () at /lib64/libgobject-2.0.so.0
#18 0x00007fb885a8e539 in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0
#19 0x00007fb885a96ef0 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#20 0x00007fb885a97765 in g_signal_emit_by_name () at /lib64/libgobject-2.0.so.0
#21 0x00007fb88ea32db5 in _folks_persona_store_emit_personas_changed () at /lib64/libfolks.so.25
#22 0x00007fb88ec8341b in ___lambda11__gsource_func () at /lib64/libfolks-eds.so.25
#23 0x00007fb88ec8a833 in __edsf_persona_store_idle_process_gsource_func () at /lib64/libfolks-eds.so.25
#24 0x00007fb88577ca8a in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#25 0x00007fb88577ce20 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#26 0x00007fb88577cecc in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#27 0x00007fb885d682e9 in g_application_run () at /lib64/libgio-2.0.so.0
#28 0x00000000004207ea in _vala_main ()
#29 0x00007fb885393790 in __libc_start_main () at /lib64/libc.so.6
#30 0x00000000004101d9 in _start ()

Comment 12 David Woodhouse 2015-07-13 22:43:54 UTC
Was it updating the EWS GAL when this happened? Look in ~/.cache/evolution/addressbook, and run 'du' to find the directory in there which is huge.

when were the contents updated?

Comment 13 Jacob Keller 2015-07-13 22:49:12 UTC
Probably? the largest size is 800Mb

The contacts.db is 414Mb, and it was the most recent update at July 13th, 15:46, though this is more recent than my last freeze.

It's most likely related to the EWS GAL.. it's just a huge headache when it freezes my machine up.

Comment 14 Luke Hinds 2015-10-30 10:21:25 UTC
Was there ever a resolution for this?

I am on Fedora 22 and using Evolution EWS and gnome-contacts-search-provider grows to consume 4GB of memory and gnome shell grinds to a halt.

http://i.imgur.com/VtDyCNt.png

Comment 15 David Woodhouse 2015-11-19 21:38:26 UTC
Apparently also seen in Fedora 23. Reopening...

Comment 16 Jacob Keller 2015-11-19 21:50:50 UTC
Yes this is still recurring on Fedora 23. I will try to get a stack trace again when it occurs next time. It seems to occur less often now.

Comment 17 René Ribaud 2015-11-25 13:31:37 UTC
Same on F22 currently. Release gnome-contacts-3.16.2-5.fc22.x86_64.

Comment 18 Elad Alfassa 2015-11-25 13:52:22 UTC
Is there an upstream bug filed for this? It is unlikely that relevant developers will see this if it stays downstream.

Comment 19 René Ribaud 2015-11-25 14:04:10 UTC
This one looks pretty similar.
https://bugzilla.gnome.org/show_bug.cgi?id=747929

Comment 20 David Woodhouse 2016-03-14 23:28:34 UTC
Happy (belated) third birthday, bug #919889.

Comment 21 Chad Versace 2016-07-14 15:14:09 UTC
Seen on Fedora 24 too (gnome-contacts-3.20.0-1.fc24.x86_64.rpm). I see the problem on a large CardDAV account and on a corporate Exhange account.

Comment 22 Jacob Keller 2016-07-22 21:32:00 UTC
I still see this with gnome-contacts-3.20.0-1.fc24.x86_64

I have a backtrace from gdb this time using all threads. Since on my system the symptom is a massive memory leak I am attempting to see if I can trick it into starting under valgrind or a similar memory debugging tool next time it runs.

Thread 6 (Thread 0x7f844d638700 (LWP 8836)):
#0  0x00007f8459836fdd in poll () at /lib64/libc.so.6
#1  0x00007f8459b4b16c in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f8459b4b27c in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007f8459b4b2b9 in glib_worker_main () at /lib64/libglib-2.0.so.0
#4  0x00007f8459b71835 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f846028060a in start_thread () at /lib64/libpthread.so.0
#6  0x00007f8459842a4d in clone () at /lib64/libc.so.6

Thread 5 (Thread 0x7f844ce37700 (LWP 8837)):
#0  0x00007f8459836fdd in poll () at /lib64/libc.so.6
#1  0x00007f8459b4b16c in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f8459b4b4f2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#3  0x00007f845a16c336 in gdbus_shared_thread_func () at /lib64/libgio-2.0.so.0
#4  0x00007f8459b71835 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f846028060a in start_thread () at /lib64/libpthread.so.0
#6  0x00007f8459842a4d in clone () at /lib64/libc.so.6

Thread 4 (Thread 0x7f8447fff700 (LWP 8840)):
#0  0x00007f8459836fdd in poll () at /lib64/libc.so.6
#1  0x00007f8459b4b16c in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f8459b4b27c in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007f844c4312ad in dconf_gdbus_worker_thread () at /usr/lib64/gio/modules/libdconfsettings.so
#4  0x00007f8459b71835 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f846028060a in start_thread () at /lib64/libpthread.so.0
#6  0x00007f8459842a4d in clone () at /lib64/libc.so.6

Thread 3 (Thread 0x7f84477fe700 (LWP 8841)):
#0  0x00007f8459836fdd in poll () at /lib64/libc.so.6
#1  0x00007f8459b4b16c in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f8459b4b4f2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#3  0x00007f8461aefa34 in source_registry_object_manager_thread () at /lib64/libedataserver-1.2.so.21
#4  0x00007f8459b71835 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f846028060a in start_thread () at /lib64/libpthread.so.0
#6  0x00007f8459842a4d in clone () at /lib64/libc.so.6

Thread 2 (Thread 0x7f842d6eb700 (LWP 8858)):
#0  0x00007f8459836fdd in poll () at /lib64/libc.so.6
#1  0x00007f8459b4b16c in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f8459b4b4f2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#3  0x00007f846260a383 in book_client_dbus_thread () at /lib64/libebook-1.2.so.16
#4  0x00007f8459b71835 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f846028060a in start_thread () at /lib64/libpthread.so.0
#6  0x00007f8459842a4d in clone () at /lib64/libc.so.6

Thread 1 (Thread 0x7f846369da80 (LWP 8722)):
#0  0x00007f845978c38f in vfprintf () at /lib64/libc.so.6
#1  0x00007f8459853f95 in __vasprintf_chk () at /lib64/libc.so.6
#2  0x00007f8459b8e939 in g_vasprintf () at /lib64/libglib-2.0.so.0
#3  0x00007f8459b6937d in g_strdup_vprintf () at /lib64/libglib-2.0.so.0
#4  0x00007f8459b515d2 in g_logv () at /lib64/libglib-2.0.so.0
#5  0x00007f8459b5198f in g_log () at /lib64/libglib-2.0.so.0
#6  0x00007f8462c9daeb in _folks_individual_aggregator_personas_changed_cb.isra.10 () at /lib64/libfolks.so.25
#7  0x00007f8462ca66cf in g_cclosure_user_marshal_VOID__OBJECT_OBJECT_STRING_OBJECT_ENUM () at /lib64/libfolks.so.25
#8  0x00007f8459e497a5 in g_closure_invoke () at /lib64/libgobject-2.0.so.0
#9  0x00007f8459e5b851 in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0
#10 0x00007f8459e64530 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#11 0x00007f8459e64dc5 in g_signal_emit_by_name () at /lib64/libgobject-2.0.so.0
#12 0x00007f8462ca6a05 in _folks_persona_store_emit_personas_changed () at /lib64/libfolks.so.25
#13 0x00007f8462ef634b in ___lambda16__gsource_func () at /lib64/libfolks-eds.so.25
#14 0x00007f8462efdba0 in __edsf_persona_store_idle_process_gsource_func () at /lib64/libfolks-eds.so.25
#15 0x00007f8459b4ae3a in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#16 0x00007f8459b4b1d0 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#17 0x00007f8459b4b27c in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#18 0x00007f845a135a96 in g_application_run () at /lib64/libgio-2.0.so.0
#19 0x0000556f73dc6d4a in _vala_main ()
#20 0x00007f8459760580 in __libc_start_main () at /lib64/libc.so.6
#21 0x0000556f73db62f9 in _start ()

Thread 6 (Thread 0x7f844d638700 (LWP 8836)):
#0  0x00007f8459836fdd in poll () at /lib64/libc.so.6
#1  0x00007f8459b4b16c in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f8459b4b27c in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007f8459b4b2b9 in glib_worker_main () at /lib64/libglib-2.0.so.0
#4  0x00007f8459b71835 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f846028060a in start_thread () at /lib64/libpthread.so.0
#6  0x00007f8459842a4d in clone () at /lib64/libc.so.6

Thread 5 (Thread 0x7f844ce37700 (LWP 8837)):
#0  0x00007f8459836fdd in poll () at /lib64/libc.so.6
#1  0x00007f8459b4b16c in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f8459b4b4f2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#3  0x00007f845a16c336 in gdbus_shared_thread_func () at /lib64/libgio-2.0.so.0
#4  0x00007f8459b71835 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f846028060a in start_thread () at /lib64/libpthread.so.0
#6  0x00007f8459842a4d in clone () at /lib64/libc.so.6

Thread 4 (Thread 0x7f8447fff700 (LWP 8840)):
#0  0x00007f8459836fdd in poll () at /lib64/libc.so.6
#1  0x00007f8459b4b16c in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f8459b4b27c in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007f844c4312ad in dconf_gdbus_worker_thread () at /usr/lib64/gio/modules/libdconfsettings.so
#4  0x00007f8459b71835 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f846028060a in start_thread () at /lib64/libpthread.so.0
#6  0x00007f8459842a4d in clone () at /lib64/libc.so.6

Thread 3 (Thread 0x7f84477fe700 (LWP 8841)):
#0  0x00007f8459836fdd in poll () at /lib64/libc.so.6
#1  0x00007f8459b4b16c in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f8459b4b4f2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#3  0x00007f8461aefa34 in source_registry_object_manager_thread () at /lib64/libedataserver-1.2.so.21
#4  0x00007f8459b71835 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f846028060a in start_thread () at /lib64/libpthread.so.0
#6  0x00007f8459842a4d in clone () at /lib64/libc.so.6

Thread 2 (Thread 0x7f842d6eb700 (LWP 8858)):
#0  0x00007f8459836fdd in poll () at /lib64/libc.so.6
#1  0x00007f8459b4b16c in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f8459b4b4f2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#3  0x00007f846260a383 in book_client_dbus_thread () at /lib64/libebook-1.2.so.16
#4  0x00007f8459b71835 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f846028060a in start_thread () at /lib64/libpthread.so.0
#6  0x00007f8459842a4d in clone () at /lib64/libc.so.6

Thread 1 (Thread 0x7f846369da80 (LWP 8722)):
#0  0x00007f845978c38f in vfprintf () at /lib64/libc.so.6
#1  0x00007f8459853f95 in __vasprintf_chk () at /lib64/libc.so.6
#2  0x00007f8459b8e939 in g_vasprintf () at /lib64/libglib-2.0.so.0
#3  0x00007f8459b6937d in g_strdup_vprintf () at /lib64/libglib-2.0.so.0
#4  0x00007f8459b515d2 in g_logv () at /lib64/libglib-2.0.so.0
#5  0x00007f8459b5198f in g_log () at /lib64/libglib-2.0.so.0
#6  0x00007f8462c9daeb in _folks_individual_aggregator_personas_changed_cb.isra.10 () at /lib64/libfolks.so.25
#7  0x00007f8462ca66cf in g_cclosure_user_marshal_VOID__OBJECT_OBJECT_STRING_OBJECT_ENUM () at /lib64/libfolks.so.25
#8  0x00007f8459e497a5 in g_closure_invoke () at /lib64/libgobject-2.0.so.0
#9  0x00007f8459e5b851 in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0
#10 0x00007f8459e64530 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#11 0x00007f8459e64dc5 in g_signal_emit_by_name () at /lib64/libgobject-2.0.so.0
#12 0x00007f8462ca6a05 in _folks_persona_store_emit_personas_changed () at /lib64/libfolks.so.25
#13 0x00007f8462ef634b in ___lambda16__gsource_func () at /lib64/libfolks-eds.so.25
#14 0x00007f8462efdba0 in __edsf_persona_store_idle_process_gsource_func () at /lib64/libfolks-eds.so.25
#15 0x00007f8459b4ae3a in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#16 0x00007f8459b4b1d0 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#17 0x00007f8459b4b27c in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#18 0x00007f845a135a96 in g_application_run () at /lib64/libgio-2.0.so.0
#19 0x0000556f73dc6d4a in _vala_main ()

Comment 23 Cristian Contescu 2017-01-29 20:25:53 UTC
The problem is still seen in Fedora 25. The workaround i found is going to Settings->Search and disable the Contacts search.

Hope there will be a better solution in the future.

Comment 24 J Freyensee 2017-04-04 21:20:23 UTC
I see this as well.  As soon as I killed the process in system monitor, Fedora 25 was noticeably faster and more smooth.

Comment 25 Fedora End Of Life 2017-07-25 18:32:23 UTC
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is 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  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

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.

Comment 26 David Woodhouse 2017-08-01 15:36:01 UTC
I don't believe this got fixed yet...

Comment 27 benjamin.esquivel 2017-08-01 16:04:49 UTC
I haven't seen this bug in Fedora 26. Though I haven't added any external accounts yet. I'll give it a try.

Comment 28 David Woodhouse 2017-08-01 19:18:26 UTC
The EWS Global Address List is the best way to trigger this, as it has a tendency to add tens or even hundreds of thousands of contacts in a single hit.

Comment 29 J Freyensee 2017-08-02 15:08:50 UTC
Yes, I haven't seen anything on this bug that suggests it is fixed.  There's been Fedora end-of-life notices since 2013 which seems to close this bug each time.

Comment 30 Jan Kurik 2017-08-15 07:26:52 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

Comment 31 Ben Cotton 2018-11-27 18:36:33 UTC
This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is 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  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

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.

Comment 32 Ben Cotton 2018-11-30 17:41:55 UTC
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 33 Eero Tamminen 2020-03-26 11:05:54 UTC
Upstream bug has moved to GitLab and is still open: https://gitlab.gnome.org/GNOME/gnome-contacts/issues/62

And this is still happening in Fedora 31, which is not EOL.  Could somebody re-open this (for some reason I can only comment)?

One workaround is disabling EWS account global address list caching, removing the already downloaded cache and rebooting.

=> I think EWS global address list caching (in Evolution -> File -> Preferences -> Mail Accounts -> <EWS account> -> Receiving Options) should be disabled by default until this cache handling has been fixed.


Note You need to log in before you can comment on or make changes to this bug.