Bug #259

SSL_connect blocking forever

Added by Alexandr Panko over 6 years ago. Updated 9 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


Linux pc 4.3.3-gentoo.r4 #3 SMP Tue Mar 8 14:53:19 MSK 2016 x86_64 AMD Phenom(tm) 9650 Quad-Core Processor AuthenticAMD GNU/Linux

Issue description.
GUI blocks after a while of working.

Conditions to reproduce.
Not simply reproducible, because of probability nature.
I have a number of SSL POP3 accounts. During this week issue start to occur. Maybe caused by not reliable ISP connection or change on SSL server side.
Have several SSL accounts from different servers, but blocking start to occur for account.

My tracing and debugging:
(gdb) bt
#0 0x00007f64b936c15d in read () from /lib64/
#1 0x00007f64bb78ce09 in ?? () from /usr/lib64/
#2 0x00007f64bb78ac3a in BIO_read () from /usr/lib64/
#3 0x00007f64b881311d in ssl23_read_bytes () from /usr/lib64/
#4 0x00007f64b88120f2 in ssl23_connect () from /usr/lib64/
#5 0x00007f64bbb16468 in ssl_init_socket_with_method (sockinfo=sockinfo@entry=0x1d624f0, method=<optimized out>, method@entry=SSL_METHOD_SSLv23) at ssl.c:261
#6 0x00007f64bbb16a87 in ssl_init_socket (sockinfo=sockinfo@entry=0x1d624f0) at ssl.c:218
#7 0x00007f64bbb0f9b2 in session_connect_cb (sock=0x1d624f0, data=0x1d54300) at session.c:271
#8 0x00007f64bbb15231 in sock_connect_async_cb (source=<optimized out>, condition=G_IO_OUT, data=0xe3dde0) at socket.c:1245
#9 0x00007f64b988febc in g_main_context_dispatch () from /usr/lib64/
#10 0x00007f64b9890275 in ?? () from /usr/lib64/
#11 0x00007f64b9890334 in g_main_context_iteration () from /usr/lib64/
#12 0x00007f64baf723f1 in gtk_main_iteration () from /usr/lib64/
#13 0x00000000004cfa27 in inc_pop3_session_do (session=0xf4caf0) at inc.c:1093
#14 inc_start (inc_dialog=inc_dialog@entry=0x1d7a470) at inc.c:916
#15 0x00000000004d0f23 in inc_all_account_mail (mainwin=mainwin@entry=0xa8e8b0, autocheck=autocheck@entry=1) at inc.c:631
#16 0x00000000004d0fc0 in inc_autocheck_func (data=0xa8e8b0) at inc.c:1931
#17 0x00007f64b989099b in ?? () from /usr/lib64/
#18 0x00007f64b988febc in g_main_context_dispatch () from /usr/lib64/
#19 0x00007f64b9890275 in ?? () from /usr/lib64/
#20 0x00007f64b98905c2 in g_main_loop_run () from /usr/lib64/
#21 0x00007f64baf721c7 in gtk_main () from /usr/lib64/
#22 0x000000000042cd02 in main (argc=1, argv=0x7ffc4371fb38) at main.c:389

I checked session->nonblocking is set to 1, but socket O_NONBLOCK is not set.
I traced the source code and found this patch should fix the issue (attached in file):

if (session->ssl_type == SSL_TUNNEL) {
- sock_set_nonblocking_mode(sock, FALSE);
+ sock_set_nonblocking_mode(sock, TRUE);
if (!ssl_init_socket(sock)) {
g_warning("can't initialize SSL.");
session->state = SESSION_ERROR;

I do not know why there is "FALSE"... Have not found any version control system (GIT, SVN, CSV...) to trace the history of this change.
Maybe it is misprint, because I do not see the reasons for it to be "FALSE"...

Please, review this changes and include into code if you agree.


ssl_connec_blocking.patch (444 Bytes) ssl_connec_blocking.patch Alexandr Panko, 07/07/2016 05:21 PM

Updated by Alexandr Panko over 6 years ago

Unfortunately the patch is not fixed the issue.

Now I see repeating strings in 'sylpheed --debug' output:
(sylpheed:6219): LibSylph-WARNING **: SSL_connect(): try again

And again GUI not respond...
Nonblocking mode is set now, but retries change nothing. They are retrying endlessly.
Need to check timeout during retries.
I will try to add timeout check into the patch...


Updated by replica watches 9 months ago replica watches our watches the as world. guarantee quality ones.

Also available in: Atom PDF