Thanks for the clarification, Daniel. From what I understood I think
it would make sense to copy the SSL session information from the
original easy handle into the spare closure handle, just like
Vuurvlieg suggested. The SSL session information may be considered
part of the connection state since
2013/5/7 Daniel Stenberg dan...@haxx.se:
Just to clarify: we can close #1219 now then?
https://sourceforge.net/p/curl/bugs/1219/
Yes, since my commit fixes the invalid memory access which leads to the crash.
---
List admin:
2013/5/4 Marc Hoersken i...@marc-hoersken.de:
I just found a new way to workaround this problem with the state being
replaced.
The attached patch introduces a new field in the internal session
structure to keep track of the currently cached session.
With this change the invalid memory
On Sat, 4 May 2013, Marc Hoersken wrote:
I have no clue why there is a need for something like a closure_handle. Why
can't the connection be freed with it's original handle? Daniel, can you
elaborate on this one?
Sure. This is necessary because we do have connections that are independent of
2013/4/29 Daniel Stenberg dan...@haxx.se
Could be, sure. But I gave this a glance and it wasn't obvious to me where
the problem is...
I was looking into this issue again, but I still cannot understand why
data-state.session is NULL in Curl_ssl_getsessionid during
Curl_ssl_shutdown.
gdb.log
On Sat, May 4, 2013 at 7:31 PM, Marc Hoersken i...@marc-hoersken.de wrote:
I was looking into this issue again, but I still cannot understand why
data-state.session is NULL in Curl_ssl_getsessionid during
Curl_ssl_shutdown.
It is because of the line @ multi.c:1767
conn-data =
I just found a new way to workaround this problem with the state being replaced.
The attached patch introduces a new field in the internal session
structure to keep track of the currently cached session.
With this change the invalid memory access is gone and the Schannel
Credential handle
2013/5/4 Vuurvlieg vuurvl...@gmail.com:
It is because of the line @ multi.c:1767
conn-data = multi-closure_handle;
It replaces the correct state (which has session properly allocated) with
the closure_handle which does not have it.
I can't figure out the correct fix.
Should it be illegal
On Sun, 28 Apr 2013, Marc Hoersken wrote:
Yes, it's probably the fact that the schannel code uses
Curl_ssl_getsessionid within the Curl_ssl_shutdown function which may not be
supported by the ssl abstraction layer.
Could be, sure. But I gave this a glance and it wasn't obvious to me where
Hi Daniel,
2013/4/20 Daniel Stenberg dan...@haxx.se:
Any chance one of you can get some debug info there so that we get to know
on what exact source line it crashes and some variable/argument contents?
Here are the details you asked for:
(gdb) run
Starting program: d:\OS\curl\src\curl.exe -g
On Fri, 19 Apr 2013, Marc Hoersken wrote:
Your other investigation were correct, too. I just verified the crash
location with gdb:
Program received signal SIGSEGV, Segmentation fault.
0x00414070 in Curl_ssl_getsessionid ()
(gdb) bt
#0 0x00414070 in Curl_ssl_getsessionid ()
#1 0x00422074
2013/4/18 Vuurvlieg vuurvl...@gmail.com:
This results in a curl binary with the crash reported in the first post.
When testing your binary did you make sure you used https protocol?
Yes, of course. I used the curl command that you posted.
I also used the exact same build steps on Windows 7 SP1
Hi
On 18 April 2013 19:56, Vuurvlieg vuurvl...@gmail.com wrote:
[...]
I build it like this in the MinGW shell:
$ ./buildconf
buildconf: autoconf version 2.68 (BAD)
Unpatched version generates unusable configure script.
[...]
Is this not perhaps a problem?
--
Michael Wood
2013/4/19 Michael Wood esiot...@gmail.com:
Hi
On 18 April 2013 19:56, Vuurvlieg vuurvl...@gmail.com wrote:
[...]
I build it like this in the MinGW shell:
$ ./buildconf
buildconf: autoconf version 2.68 (BAD)
Unpatched version generates unusable configure script.
[...]
Is this
On Fri, Apr 19, 2013 at 10:33 AM, Marc Hoersken i...@marc-hoersken.dewrote:
Since WinSSL is heavily tied into the OS, on which Windows version
are you experiencing this issue?
My windows version is:
Windows 7 Ultimate 64-bit (6.1, Build 7601) Service Pack 1
(7601.win7sp1_gdr.130104-1431)
Is
Hi there,
2013/4/18 Vuurvli3g vuurvl...@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
Thanks for your response.
2013/4/18 Marc Hoersken i...@marc-hoersken.de
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
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
18 matches
Mail list logo
