Hi.

We have integrated libcurl 7.12.3 into a multi-threaded application and
built on Linux (RedHat Enterprise Server 3). A customer has experienced
some segmentation faults when the application is configured to use a
HTTP proxy and is attempting a POST request - in each case the stack
trace looks as follows:

#0 0x080eb58a in strcasecmp ()
#1 0x001845ce in curl_strequal (first=0x0, second=0xb7198e48
"svr-prd-web-001") at strequal.c:40
#2 0x00178d5e in ConnectionExists (data=0xb718f658, needle=0xb719bf20,
usethis=0xf692e0) at url.c:1605
#3 0x0017a330 in CreateConnection (data=0xb718f658,
in_connect=0x5582148, addr=0x55820e8, async=0x558211b "") at url.c:3111
#4 0x0017b50b in Curl_connect (data=0xb718f658, in_connect=0x5582148,
asyncp=0x558211b "") at url.c:3483
#5 0x00184165 in Curl_connect_host (data=0xb718f658, conn=0x5582148) at
transfer.c:2045
#6 0x00184272 in Curl_perform (data=0xb718f658) at transfer.c:2104
#7 0x0018499f in curl_easy_perform (curl=0xb718f658) at easy.c:389

So it seems there is a NULL pointer being passed into strcasecmp,
causing the crash. It looks like it is the proxy.name that is NULL.
Also, this only seems to happen after a previous call to
curl_easy_perform() (using the same CURL* handle) returned
CURLE_COULDNT_RESOLVE_PROXY (which in turn seems to have been caused by
the DNS name look-up timing out).
Unfortunately I have not been able to reproduce this in-house and am
relying on traces/logs sent by the customer.
Is this a known issue with this version (I couldn't find any reference
to in the archives), and if not, can you see how this could happen under
these circumstances?
In the meantime, I guess a work-around would be to destroy the existing
CURL* handle and create a new one in the case of a
CURLE_COULDNT_RESOLVE_PROXY?

Rgds,
James Bailey
Received on 2005-08-16