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 741238 - Evo is unusable and uses 100% CPU trying to reconnect
Evo is unusable and uses 100% CPU trying to reconnect
Status: RESOLVED DUPLICATE of bug 748996
Product: evolution-data-server
Classification: Platform
Component: general
unspecified
Other Linux
: Normal major
: ---
Assigned To: Evolution Shell Maintainers Team
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2014-12-08 09:02 UTC by Milan Bouchet-Valat
Modified: 2018-02-09 20:41 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Backtrace of all threads (23.81 KB, text/plain)
2014-12-08 09:02 UTC, Milan Bouchet-Valat 		Details
Backtrace of all threads (30.21 KB, text/plain)
2014-12-08 09:03 UTC, Milan Bouchet-Valat 		Details

Description Milan Bouchet-Valat 2014-12-08 09:02:17 UTC 
Created attachment 292288 [details]
Backtrace of all threads

After resuming from suspend, Evo kept trying to reconnect my IMAPX accounts, not succeeding, and using all 4 CPU cores at 100%. The UI was responsive, but trying to cancel the current operations had no effect, neither did the online/offline button in the bottom-left corner, I had to close Evo.

Attached is a backtrace of all threads.

This is with Evo 3.12.8 on Fedora 21.
Comment 1 Milan Bouchet-Valat 2014-12-08 09:03:51 UTC 
Created attachment 292290 [details]
Backtrace of all threads

Woops, I attached the wrong gdb.txt.
Comment 2 Milan Bouchet-Valat 2014-12-08 10:55:59 UTC 
See also bug 691966.
Comment 3 Milan Crha 2014-12-09 15:27:46 UTC 
Thanks for a bug report. What's the GLib version you have, please? As all the threads look quite similar to the one pasted below (for better searching), then I'm moving this to GLib.

+ Trace 234409

Thread 6 (Thread 0x7fe711aeb700 (LWP 28075))

  • #0 syscall
    at ../sysdeps/unix/sysv/linux/x86_64/syscall.S line 38
  • #1 g_mutex_lock_slowpath
    at gthread-posix.c line 1308
  • #2 g_mutex_lock
    at gthread-posix.c line 1332
  • #3 g_logv
    at gmessages.c line 1002
  • #4 g_log
    at gmessages.c line 1079
  • #5 g_list_foreach
    at glist.c line 993
  • #6 g_list_free_full
    at glist.c line 217
  • #7 g_network_address_address_enumerator_next
    at gnetworkaddress.c line 873
  • #8 g_proxy_address_enumerator_next
    at gproxyaddressenumerator.c line 210
  • #9 g_network_monitor_base_can_reach
    at gnetworkmonitorbase.c line 194
  • #10 camel_network_service_can_reach_sync
    at camel-network-service.c line 1027
  • #11 camel_offline_store_set_online_sync
    at camel-offline-store.c line 195
  • #12 e_mail_store_go_online_sync
    at e-mail-store-utils.c line 268
  • #13 mail_store_go_online_thread
    at e-mail-store-utils.c line 285
  • #14 run_in_thread
    at gsimpleasyncresult.c line 858
  • #15 io_job_thread
    at gioscheduler.c line 85
  • #16 g_task_thread_pool_thread
    at gtask.c line 1215
  • #17 g_thread_pool_thread_proxy
    at gthreadpool.c line 307
  • #18 g_thread_proxy
    at gthread.c line 764
  • #19 start_thread
    at pthread_create.c line 310
  • #20 clone 






Comment 4


Milan Bouchet-Valat





          2014-12-09 15:53:29 UTC
        



That's version 2.42.1.






Comment 5


Michael Catanzaro





          2018-02-09 20:31:14 UTC
        




*** This bug has been marked as a duplicate of bug 748996 ***






Comment 6


Michael Catanzaro





          2018-02-09 20:35:48 UTC
        



BTW I'm suspicious of the camel code here too. It's using the *same* GNetworkMonitor in multiple threads, which is not expected to be safe. So I think there's actually separate e-d-s and glib-networking bugs involved here.






Comment 7


Michael Catanzaro





          2018-02-09 20:36:33 UTC
        



(In reply to Michael Catanzaro from comment #6)
> BTW I'm suspicious of the camel code here too. It's using the *same*
> GNetworkMonitor in multiple threads, which is not expected to be safe. So I
> think there's actually separate e-d-s and glib-networking bugs involved here.

CamelNetworkService sometimes guards use of the GNetworkMonitor with a mutex, but not in the codepath seen in the backtrace.






Comment 8


Michael Catanzaro





          2018-02-09 20:41:46 UTC
        



Actually, looking over bug #748996, looks like it really is considered a bug for GNetworkMonitor to not be threadsafe.

*** This bug has been marked as a duplicate of bug 748996 ***