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 733868 - Sending mail hangs when autocomplete with Gmail contacts address book is enabled.
Sending mail hangs when autocomplete with Gmail contacts address book is enab...
Status: RESOLVED DUPLICATE of bug 733081
Product: evolution
Classification: Applications
Component: Contacts
3.12.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: evolution-addressbook-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2014-07-28 14:41 UTC by Christian Dysthe
Modified: 2014-08-12 16:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Stacktrace (55.17 KB, text/x-log)
2014-08-05 09:35 UTC, Dominik Grafenhofer
Details

Description Christian Dysthe 2014-07-28 14:41:16 UTC
When I have autocomplete enabled with my Gmail contacts address book sending mail hangs on "Sending Message" and I have to kill Evolution. There's no problem with auto complete and local address books and no problems if I disabled auto complete for my Gmail contacts address book.

This is terminal output for sending with autocomplete enabled:

(evolution:6320): evolution-util-CRITICAL **: e_contact_store_get_contact: assertion 'ITER_IS_VALID (contact_store, iter)' failed

(evolution:6320): evolution-util-CRITICAL **: e_contact_store_get_contact: assertion 'ITER_IS_VALID (contact_store, iter)' failed

(evolution:6320): libebook-contacts-CRITICAL **: e_contact_get: assertion 'contact && E_IS_CONTACT (contact)' failed

(evolution:6320): libebook-contacts-CRITICAL **: e_contact_get: assertion 'contact && E_IS_CONTACT (contact)' failed

(evolution:6320): libebook-contacts-CRITICAL **: e_contact_get: assertion 'contact && E_IS_CONTACT (contact)' failed

I have tried to remove and add the Gmail contacts but the problem remains.
Comment 1 André Klapper 2014-07-28 22:53:04 UTC
What does "hang" mean (how long did you wait)? 
And can you provide a stacktrace when it hangs?
Comment 2 Christian Dysthe 2014-07-28 23:31:24 UTC
It hangs indefinitely on the last part where it says "Sending Message". The compose window never closes so I have to kill Evo. However, the e-mail is being sent. I will look into getting a stacktrace.
Comment 3 Christian Dysthe 2014-07-29 17:32:28 UTC
Not being a developer I am not ale create a stacktrace. I do however have the same problem on three machines with Evolution 3.12.4 and it should be easy to reproduce.
Comment 4 André Klapper 2014-07-29 20:46:37 UTC
Please see https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces for how to gather a stacktrace. You don't need to be a developer for that. :)
Comment 5 Christian Dysthe 2014-07-30 19:15:41 UTC
I had to downgrade to 3.10 since this is my work machine and it took me ages addressing mail in addition to other problems i had with Evo 3.12. I will get back on 3.12 in a couple of days and try to do the stacktrace. 3.10 works perfectly.
Comment 6 Jürg Billeter 2014-08-05 08:32:31 UTC
I see the same issue with 3.12.4 on two systems and I don't think it ever happened with 3.12.3. It's very annoying as I never know whether the mail got out or not. I believe it typically hangs after sending the mail, however, it doesn't get stored in the (IMAP) Sent folder.

It happens very frequently but not every time. Sending a mail right after restarting evolution (using --force-shutdown to kill it first) typically works. This is with a stable (wired) internet connection.

In contrast to Christian, I do not have a Gmail address book configured at all, just a local one.

Increasing severity to critical as the mail is not stored in the Sent folder and thus, there is data loss.

Thread 6 (Thread 0x7fbefffff700 (LWP 3662))

  • #0 __lll_lock_wait
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S line 135
  • #1 _L_lock_1134
    from /lib/libpthread.so.0
  • #2 __GI___pthread_mutex_lock
    at ../nptl/pthread_mutex_lock.c line 114
  • #3 camel_imapx_server_ref_job
    at camel-imapx-server.c line 9411
  • #4 camel_imapx_store_ref_job
    at camel-imapx-store.c line 3313
  • #5 imapx_server_ref_job
    at camel-imapx-server.c line 1800
  • #6 camel_imapx_server_refresh_info
    at camel-imapx-server.c line 8596
  • #7 imapx_refresh_info_sync
    at camel-imapx-folder.c line 852
  • #8 camel_folder_refresh_info_sync
    at camel-folder.c line 3482
  • #9 folder_refresh_info_thread
    at camel-folder.c line 3502
  • #10 g_task_thread_pool_thread
    at gtask.c line 1213
  • #11 g_thread_pool_thread_proxy
    at gthreadpool.c line 307
  • #12 g_thread_proxy
    at gthread.c line 764
  • #13 start_thread
    at pthread_create.c line 309
  • #14 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 111

Thread 5 (Thread 0x7fbf4affd700 (LWP 3748))

  • #0 __lll_lock_wait
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S line 135
  • #1 _L_lock_1134
    from /lib/libpthread.so.0
  • #2 __GI___pthread_mutex_lock
    at ../nptl/pthread_mutex_lock.c line 114
  • #3 camel_imapx_server_ref_job
    at camel-imapx-server.c line 9411
  • #4 camel_imapx_store_ref_job
    at camel-imapx-store.c line 3313
  • #5 imapx_server_ref_job
    at camel-imapx-server.c line 1800
  • #6 camel_imapx_server_refresh_info
    at camel-imapx-server.c line 8596
  • #7 imapx_refresh_info_sync
    at camel-imapx-folder.c line 852
  • #8 camel_folder_refresh_info_sync
    at camel-folder.c line 3482
  • #9 refresh_folders_exec
    at mail-send-recv.c line 1030
  • #10 mail_msg_proxy
    at mail-mt.c line 373
  • #11 g_thread_pool_thread_proxy
    at gthreadpool.c line 307
  • #12 g_thread_proxy
    at gthread.c line 764
  • #13 start_thread
    at pthread_create.c line 309
  • #14 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 111

Thread 2 (Thread 0x7fbeff7fe700 (LWP 3800))

  • #0 __lll_lock_wait
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S line 135
  • #1 _L_lock_1134
    from /lib/libpthread.so.0
  • #2 __GI___pthread_mutex_lock
    at ../nptl/pthread_mutex_lock.c line 114
  • #3 camel_imapx_server_ref_job
    at camel-imapx-server.c line 9411
  • #4 camel_imapx_store_ref_job
    at camel-imapx-store.c line 3313
  • #5 imapx_server_ref_job
    at camel-imapx-server.c line 1800
  • #6 camel_imapx_server_refresh_info
    at camel-imapx-server.c line 8596
  • #7 imapx_refresh_info_sync
    at camel-imapx-folder.c line 852
  • #8 camel_folder_refresh_info_sync
    at camel-folder.c line 3482
  • #9 folder_refresh_info_thread
    at camel-folder.c line 3502
  • #10 g_task_thread_pool_thread
    at gtask.c line 1213
  • #11 g_thread_pool_thread_proxy
    at gthreadpool.c line 307
  • #12 g_thread_proxy
    at gthread.c line 764
  • #13 start_thread
    at pthread_create.c line 309
  • #14 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 111

Comment 7 Dominik Grafenhofer 2014-08-05 08:56:47 UTC
I can confirm all observations from Jürg Billeter on Fedora 20 (using Gnome 3.12 from Copr). Only difference: I use owncloud CARDDAV addressbooks and CALDAV calendars via gnome online accounts.
Comment 8 Dominik Grafenhofer 2014-08-05 09:35:17 UTC
Created attachment 282532 [details]
Stacktrace
Comment 9 Jürg Billeter 2014-08-08 16:08:33 UTC
Possibly duplicate of bug 733081. I'll test whether I can still reproduce the issue with the fixes from the 3.12 branch.
Comment 10 Dominik Grafenhofer 2014-08-11 07:17:15 UTC
The patch attached to bug #733081 seems to have fixed the problem for me. After two days of testing, I did not have a single hang anymore.
Comment 11 Jürg Billeter 2014-08-12 16:49:28 UTC
Yes, same here.

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