Bugs item #917642, was opened at 2004-03-16 14:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=917642&group_id=976

Category: https
Group: bad behaviour
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Daniel Stenberg (bagder)
Summary: SSL connect blocks curl_multi_perform

Initial Comment:
curl 7.11.0 (i686-pc-linux-gnu) libcurl/7.11.0
OpenSSL/0.9.6b zlib/1.1.4
Protocols: ftp gopher telnet dict ldap http file https
ftps
Features: SSL libz NTLM
----------------------------------------------------------
I am using HTTPS post requests to create a secure
connection to a server. The client (libcurl) side uses
the multi interface calling curl_multi_perform every
10ms or so from a timer dispatched by the UI package
(fltk) which blocks the UI during the processing of the
timer. I have been assuming that curl_multi_perform is
essentially a non-blocking interface and therefore is
ok to call in this way (which it is nearly all of the
time). However, if the server (apache) shuts down
while the client is establishing a connection,
libcurl's curl_multi_perform can get stuck in a select
call waiting for openssl to connect. If I attach gdb
when in this state I get the following backtrace:
----------------------------------------------------------
#0 0x420d3b2e in select () from /lib/i686/libc.so.6
#1 0x40244f08 in __JCR_LIST__ () from
/usr/lib/libcurl.so.2
#2 0x402285cf in Curl_http_connect (conn=0x0) at
http.c:971
#3 0x4022edab in Curl_protocol_connect
(conn=0x88206e0, hostaddr=0x0)
    at url.c:1908
#4 0x4023cb92 in curl_multi_perform
(multi_handle=0x8723ab8,
    running_handles=0xbffff464) at multi.c:413
----------------------------------------------------------
Is this a bug or is my assumption about the
non-blocking nature of curl_multi_perform simply wrong?

Thanks,

Stuart Lovett
stupublic_at_yahoo.com

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=917642&group_id=976
Received on 2004-03-16