Hi there,

2013/4/18 Vuurvli3g <vuurvlieg_at_gmail.com>
> I recently started using libcurl and compiled it with MinGW.
> I wanted to use the windows built-in certs so I opted for using WinSSL.
> This combination crashes. Can easily be reproduced: just run curl.exe -g https://google.com
> The version info:
> curl 7.30.0 (i686-pc-mingw32) libcurl/7.30.0 WinSSL zlib/1.2.7
> Protocols: http https
> Features: Debug TrackMemory GSS-Negotiate Largefile NTLM SSL SSPI libz

I just tried the same command and can't reproduce the crash using the
latest version from the git repository:

$ curl -V
curl 7.30.1-DEV (i686-pc-mingw32) libcurl/7.30.1-DEV WinSSL zlib/1.2.7
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
pop3 pop3s rtsp smtp smtps telnet tftp
Features: Debug GSS-Negotiate Largefile NTLM SSL SSPI libz

> I started digging into the curl code to see if I could figure out the cause and I somewhat did:
> There is a problem in the Curl_schannel_shutdown function.
> At curl_schannel.c:1146 it calls: Curl_ssl_getsessionid but at this point the data->state.session
> is not allocated.
> This is because the shutdown comes from close_all_connections at multi.c:1761
> where they swap out the original SessionHandle (which does have state.session allocated) with the multi->closure_handle.
> The line can be found at multi.c:1767
> The multi->closure_handle doesn't have the SessionHandle.state.session allocated causing a
> NULL pointer dereference.
> I am not sure what the right fix is here because I only just started looking into the code and the
> multi interface is a little hard to understand.
> First things that came to mind where:
> Is the original SessionHandle ever freed after being swapped out? potential memory leak?
> Adding NULL checks in Curl_ssl_getsessionid will 'fix' the crash but it might break the logic in Curl_schannel_shutdown because it expects to get info from the 'real' SessionHandle struct?
>
> A work around is to use --no-sessionid because Curl_ssl_getsessionid then returns at the start.

Your explanation sounds good, but since I am not familiar with the
multi interface either, I cannot verify that the multi->closure_handle
having no SessionHandle.state.session is actually correct. The
mentioned code in Curl_schannel_shutdown was recently introduced to
handle the problem of a connection being unsuccessful which would
cause the session handle not to be cached. If it wasn't cached, it
would have never been freed in Curl_schannel_session_free.

> Another note: I had link errors to the gdi32 lib when building curl with MinGW.
> So I had to make a modification at configure.am:1568 to put the gdi32 lib behind the other libs:
> LIBS="$LIBS -lgdi32"

Can't reproduce this either. Did you build curl using ./buildconf,
./configure and make with msys or did you use mingw32-make with MinGW?

Best regards,
Marc
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-04-18