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

> On Sat, 15 Jan 2005, Jochen Roderburg wrote:
>
> > 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).
>
> I know. But from that, to actually finding and fixing the error is quite a
> distance.

How true ;-)

> It would indicate that the CAFile variable otherwise is set to rubbish. The
> problem is then "just" to understand and figure out why and where that
> happens...

Yes, that is how it looks to me now. Internal the pointer seems to contain a
corrupt value, which brings the crashes, if it is not set to something else
during the running of the program.
Just for the sake of completeness, the Windows binary crashes also when you
don't use a k and cacert parameter and the internal search for the cert file
does not succeed.

To formulate it a bit philosophical: When the program source looks correct, but
the program binary does not work as expected, it is often a sign that the
binary is not the same program as the source. In our case it could be that the
pointer is set deliberately to something strange or we have the result of a
compiler error somewhere and some badly generated code which overrides the
storage.
Therefore I fear it would not help much if someone else compiles the program new
in order to debug the problem. It could well happen that his environment is so
different that the problem does not come up at all :-(

At least the case is known now and an easy workaround is possible and the
information about it can be found in the mailing-list archive.

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