problems with cached addresses - anyone?
Date: 12 Feb 2004 15:41:10 +0300
I'm new to this list / curl but I discovered a problem, with
application I'm developing and curl. (Mac OS X 10.3.2/curl 7.11.0)
[Side note: Probably this is related to the crashes recently reported
for verbose=on - as I too run 7.11 on Mac OS X, but I'm sure it's
linked correctly in my case.]
Sorry for a lot of (not useful) details, I don't know what's relevant.
It's kind of naive question, and I understand that I don't provide
enough info below, just wanted to know at first if it _can_ be curl
bug, not in the application.
The application opens and uses simultaneously two connections: one is
HTTP via proxy, another is FTP without proxy, different hosts.
The applications does few HTTP (GET) request and uploads a file via
FTP, then does the above again for the next file, etc - kind of
uploader.. Both connections are let to be "reused"..
The verbose option is set.
The problem is that at some moment, say at the 4th upload, curl
crashes in verboseconnect, in getnameinfo, because the area pointed by
conn->serv_addr contains invalid data. I.e. serv_addr is a valid
pointer, but the area it points, previously filled with valid data
(associated with the FTP host, I tracked that in gdb), is overwritten?
with some garbage.
My first thought was that that's the application that "writes in wrong
place", but I haven't been able to track it down. Finally I looked at
curl sources and now I'm thinking about a small chance that that area
is just freed and reused for some other data by the application (the
application is single-threaded and there's quite a big amount of
tossing memory in the curl callbacks / between the uploads).
So I turned off hostcache_prune in hostip.c:
/* Remove outdated and unused entries from the hostcache */
and now everything seems to work.
So could somebody say, is it possible or not, that it's due to a bug
in curl cache? Or probably you could give some hint on what I can do
to find the bug, in the application or in the curl?
Thanks for any info,
Received on 2004-02-12