http://bugs.winehq.org/show_bug.cgi?id=19406
--- Comment #9 from Juan Lang juan_lang@yahoo.com 2009-07-21 12:30:10 ---
From the failing log:
trace:winhttp:WinHttpSetTimeouts 0x3, 0, 60000, 30000, 30000 fixme:winhttp:WinHttpSetTimeouts resolve and connect timeout not supported trace:winhttp:addref_object 0x81ab4f8 -> refcount = 2 trace:winhttp:grab_object handle 0x3 -> 0x81ab4f8 warn:winhttp:netconn_set_timeout setsockopt failed (Chybný popisovač souboru) warn:winhttp:netconn_set_timeout setsockopt failed (Chybný popisovač souboru)
And, from winhttp/session.c: if (netconn_set_timeout( &request->netconn, TRUE, send )) ret = FALSE; (snip) return ret;
So I'd say the failing setsockopt is the issue. Google tells me "Chybný popisovač souboru" is "Bad file descriptor" in English.
Looking further at the log, the handle passed to WinHttpSetTimeouts is 0x3. It's created with WinHttpOpenRequest:
trace:winhttp:WinHttpOpenRequest 0x2, L"GET", L"/nucleus/authToken", (null), (null), (nil), 0x00800100 (snip) trace:winhttp:WinHttpOpenRequest returning 0x3
Note that the flags include WINHTTP_FLAG_SECURE (0x00800000). Looking at WinHttpOpenRequest,
if (!netconn_init( &request->netconn, request->hdr.flags & WINHTTP_FLAG_SECURE )) goto end;
That is, it calls netconn_init, with secure = TRUE since WINHTTP_FLAG_SECURE was set. From net.c:
BOOL netconn_init( netconn_t *conn, BOOL secure ) { conn->socket = -1; if (!secure) return TRUE;
#if defined(SONAME_LIBSSL) && defined(SONAME_LIBCRYPTO) if (libssl_handle) return TRUE;
So, conn->socket is currently set to -1, so setsockopt will fail. I'd guess that WinHttpSetTimeouts should still succeed in this case, perhaps by storing the timeouts and calling setsockopt when the connection is actually created.