This is a follow up to the email discussion I found at http://curl.haxx.se/mail/lib-2013-04/0301.html.
Compiling curl in a mingw environment with
CFG="-ipv6 -zlib -sspi -winssl -spnego -ldaps" make mingw32
creates a curl.exe binary which segfaults after closing a https connection.
Turning on the debug build I was able to gather the below stack trace.
If I can gather some more information I'd be happy to.
OS: Win7 x64 SP1 $ gdb --args curl.exe https://google.de GNU gdb (GDB) 7.5 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-mingw32". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from H:\mingwGitDevEnv_installed\packages\mingw32-curl\curl-7.30.0-1\build\src\curl.exe...done. (gdb) run Starting program: H:\mingwGitDevEnv_installed\packages\mingw32-curl\curl-7.30.0-1\build\src\curl.exe https://google.de [New Thread 3768.0x129c] [New Thread 3768.0x1244] [New Thread 3768.0x10d4] [New Thread 3768.0x1990] <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="https://www.google.de/">here</A>. </BODY></HTML> [New Thread 3768.0x1a00] [New Thread 3768.0x16a4] Program received signal SIGSEGV, Segmentation fault. 0x0041addf in Curl_ssl_getsessionid () (gdb) info stack #0 0x0041addf in Curl_ssl_getsessionid () #1 0x0042f93c in Curl_schannel_shutdown () #2 0x0041b2f0 in Curl_ssl_shutdown () #3 0x0042f5e4 in Curl_schannel_close () #4 0x0041b2d6 in Curl_ssl_close () #5 0x0042067a in Curl_disconnect () #6 0x004280f2 in close_all_connections () #7 0x00428145 in curl_multi_cleanup () #8 0x0041cd93 in Curl_close () #9 0x00414e35 in curl_easy_cleanup () #10 0x0040dd39 in operate (config=0x28fc80, argc=2, argv=0x332f70) at tool_operate.c:1744 #11 0x00408cbc in main (argc=2, argv=0x332f70) at tool_main.c:100 (gdb) quit A debugging session is active. Inferior 1 [process 3768] will be killed. Quit anyway? (y or n) y error return C:/MinGW/msys/1.0/src/gdb/gdb-7.5-1/src/gdb-7.5/gdb/windows-nat.c:1272 was 5 $uame -a MINGW32_NT-6.1 THOMAS-WIN7-X64 1.0.18(0.48/3/2) 2012-11-21 22:34 i686 Msys $ curl -V curl 7.30.0 (i386-pc-win32) libcurl/7.30.0 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: AsynchDNS GSS-Negotiate IPv6 Largefile NTLM SPNEGO SSL SSPI libz
Marc Hoersken later added detail to it:
http://curl.haxx.se/mail/lib-2013-04/0358.html
I'm hoping for someone to debug it, I don't use nor develop on windows myself.
Thanks for the report. We believe this was fixed in commit 35874298e420aa53f. Closing this issue!
I've verfied that curl 7.30 plus 35874298e420aa53f fixes the issue.
Thanks!
For the lazy people like me, here's the direct link to the fix:
https://github.com/bagder/curl/commit/35874298e420aa53fde28982d86d5051aa92279a
As this fix seems to be quite critical to me, can we expect a hotfix release soon?
I don't plan on making any intermediate release due to this problem, no.
If you want a source package as if a release had been done today, get the most recent snapshot from: http://curl.haxx.se/snapshots/
@Sebastian - The patch seems to work. No more crashing here. Thanks for the link!
@Daniel - The snapshots include a whole bunch of patches which may or may not work as the snapshots page attests to. When someone runs into this bug, it is a showstopper but they probably don't really want to run anything but the code with this specific patch. I'm sure you'll do a regular release soon anyway because this project updates fairly frequently - cURL seems to be on a monthly/bi-monthly release cycle.
Correct, we're set to do the 7.31.0 release on June 22nd.