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 723612 - addressbook factory stopped working
addressbook factory stopped working
Status: RESOLVED DUPLICATE of bug 687223
Product: evolution-data-server
Classification: Platform
Component: Contacts
3.10.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-addressbook-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2014-02-04 15:03 UTC by David Woodhouse
Modified: 2015-03-09 17:12 UTC
See Also:
GNOME target: ---
GNOME version: 3.9/3.10


Description David Woodhouse 2014-02-04 15:03:39 UTC 
It's running, apparently, but not really *doing* anything. The Evolution UI, with the typical GNOME-like lack of error reporting, just shows as if the address books are empty. Which they are definitely not.

Seems to have a whole bunch of threads stuck in getaddrinfo()

(gdb) t a a bt

+ Trace 233128

Thread 1 (Thread 0x7eff2d27d840 (LWP 21031))

  • #0 poll
    at ../sysdeps/unix/syscall-template.S line 82
  • #1 g_main_context_poll
    at gmain.c line 4007
  • #2 g_main_context_iterate
    at gmain.c line 3708
  • #3 g_main_loop_run
    at gmain.c line 3907
  • #4 dbus_server_run_server
    at e-dbus-server.c line 222
  • #5 ffi_call_unix64
    at ../src/x86/unix64.S line 76
  • #6 ffi_call
  • #7 g_cclosure_marshal_generic_va
    at gclosure.c line 1550
  • #8 _g_closure_invoke_va
    at gclosure.c line 840
  • #9 g_signal_emit_valist
    at gsignal.c line 3238
  • #10 g_signal_emit
    at gsignal.c line 3386
  • #11 e_dbus_server_run
    at e-dbus-server.c line 411
  • #12 main
    at evolution-addressbook-factory.c line 132 






Comment 1


Milan Crha





          2014-02-04 18:26:45 UTC
        



I guess your vpn got down, and the books are trying to figure out whether they still can connect.






Comment 2


David Woodhouse





          2014-02-04 18:38:20 UTC
        



Er... it was certainly up when I noticed, but I wouldn't swear that it hadn't dropped at all in the time that evo-addr-factory was running. It probably had.

Do we still have an addressbook factory which dies and stops working when the VPN drops? I thought that was expected in 3.8 but was supposed to be fixed in 3.10?






Comment 3


Milan Crha





          2015-03-09 17:12:57 UTC
        



There also landed other changes here and there, during each development cycle. Your issue is also related to the limitation of GTask, it uses a thread pool which allows only 10 threads running simultaneously. Evolution using GTask directly, or even indirectly (the GSimpleAsyncResult uses in internally, if I'm not mistaken), reaches the limit easily, especially with many accounts/sources configured. Then the real operations are waiting for the host lookup finish, starving in the GTask's queue.

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