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 650671 - Service connect/disconnect not cancelled properly
Service connect/disconnect not cancelled properly
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: Mailer
3.0.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
evolution[smtp]
Depends on:
Blocks:
 
 
Reported: 2011-05-20 13:15 UTC by Milan Bouchet-Valat
Modified: 2011-07-01 18:02 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
eds patch (1.66 KB, patch)
2011-07-01 17:56 UTC, Milan Crha 		committed Details | Review
evo patch (8.71 KB, patch)
2011-07-01 18:00 UTC, Milan Crha 		committed Details | Review

Description Milan Bouchet-Valat 2011-05-20 13:15:16 UTC 
When I set my SMTP configuration to use TLS or SSL, sending a mail fails without any proper error. "Sending message..." banner is shown, but nothing happens. Clicking Cancel changes the text, but never actually cancels. Even disconnecting the network isn't enough to cancel the process: I had to close the mail window (probably it continues in the background).

We should really get a correct error message, just like this happens with IMAP when TLS isn't supported (which didn't work some time ago, that was bug 436194).

If you want to try, the mail server is smtp.sfr.fr.
Comment 1 Milan Bouchet-Valat 2011-05-20 14:52:11 UTC 
Oh, and I got a crash when closing Evo that seems to be highly related to SMTP+SSL.

Here's the trace:
Program terminated with signal 11, Segmentation fault.

+ Trace 227193

Thread 1 (Thread 0x7f620e2fc9a0 (LWP 1815))

  • #0 ??
  • #1 g_hash_table_lookup_node
    at ghash.c line 313
  • #2 g_hash_table_lookup
    at ghash.c line 902
  • #3 g_key_file_lookup_group
    at gkeyfile.c line 3430
  • #4 g_key_file_has_key
    at gkeyfile.c line 3129
  • #5 mail_sidebar_model_loaded_row_cb
    at e-mail-sidebar.c line 113
  • #6 g_closure_invoke
    at gclosure.c line 767
  • #7 signal_emit_unlocked_R
    at gsignal.c line 3252
  • #8 g_signal_emit_valist
    at gsignal.c line 2983
  • #9 g_signal_emit
    at gsignal.c line 3040
  • #10 em_folder_tree_model_set_folder_info
    at em-folder-tree-model.c line 851
  • #11 em_folder_tree_model_set_folder_info
    at em-folder-tree-model.c line 654
  • #12 folder_tree_get_folder_info__done
    at em-folder-tree.c line 325
  • #13 folder_tree_get_folder_info__done
    at em-folder-tree.c line 224
  • #14 mail_msg_idle_cb
    at mail-mt.c line 388
  • #15 g_main_dispatch
    at gmain.c line 2440
  • #16 g_main_context_dispatch
    at gmain.c line 3013
  • #17 g_main_context_iterate
    at gmain.c line 3091
  • #18 g_main_loop_run
    at gmain.c line 3299
  • #19 gtk_main
    at gtkmain.c line 1358
  • #20 main
    at main.c line 734 






Comment 2


Milan Crha





          2011-07-01 17:51:59 UTC
        



Thanks for a bug report. Let's deal with the first issue only, not with the second. I can confirm the issue, I can reproduce it when using TLS on your SMTP server.






Comment 3


Milan Crha





          2011-07-01 17:56:01 UTC
        



Created attachment 191110 [details] [review]
eds patch

for evolution-data-server;

This change is required, because CamelOperation derives from GCancellable, thus one can cancel it by using camel_operation_cancel() or, more often, by g_cancellable_cancel(). Using the former makes the internal CamelMsgPort know about cancellation and everything works as expected, but using the later skips the CamelMsgPort update, thus it doesn't know about the change. This is fixing the issue.






Comment 4


Milan Crha





          2011-07-01 18:00:25 UTC
        



Created attachment 191111 [details] [review]
evo patch

for evolution;

CamelService is using different way for cancelling connect/disconnect. Instead of providing a cancellable as a parameter this is created on demand and used internally, to be able to cancel it by camel_service_cancel() from the offline code. That's what the comment says. I thought I will simply change the API, but after reading that comment I decided to postpone it, instead, I created a wrapper in evolution, to behave like the cancellable is passed into the CamelService.

With these two patches I can easily cancel connection any time I want while sending. Not all connect/disconnect are using cancellables, though.






Comment 5


Milan Crha





          2011-07-01 18:02:26 UTC
        



Created commit 89d6972 in eds master (3.1.3+)
Created commit 7c6aa94 in evo master (3.1.3+)