Zitat von Daniel Stenberg <daniel-curl_at_haxx.se>:

> On Sat, 15 Jan 2005, Jochen Roderburg wrote:

> > With this theory I was also now able to simulate the error under Linux. I
> > replaced the above line with data->set.ssl.CAfile = -1 and now I get also a
> > chrash under Linux with -k.
>
> But -1 is an invalid value for that pointer. It should be NULL or point to a
> zero terminated file path.
>

Correct, I wanted to see what happens when there is an invalid pointer ;-)
And the result was I get the same behaviour as with the current Windows binary.

>
> ... and the check on line 3687 prevents the strdup() to attempt to clone a
> NULL pointer.

Yes, but it does not prevent the use of a non-NULL, but somehow else invalid
pointer.

> To sum it up: I don't see where this is a problem. But maybe I'm blind!

OK, I understand now that the *expected* behaviour is that the not-explicitly
initialised pointers have a harmless NULL value and will not lead to a crash.

So it looks like the pointer corruption has some other cause and I think that
this is really now a question to the person who compiled the windows binary.
Only he would know what compile options he really had used or if he made changes
in this area regarding the CAFile variable. Remember, the result of my
experiments was that the crash disappears when you set the --cacert parameter
to anything (which in turns sets this CAFile variable intern).

Regards, J.Roderburg
Received on 2005-01-15