Daniel Stenberg wrote:
> On Tue, 21 Sep 2004, Bertrand Demiddelaer wrote:
>
>> I'm using licurl-7.12.2-20040917 on a monoprocess/monothread
>> application with curl_multi et curl_share interfaces (for dns). I
>> noticed that enabling CURLOPT_VERBOSE could cause this kind of report
>> with valgrind:
>>
>> ==29530== Invalid read of size 4
>> ==29530== at 0x807F1A4: Curl_printable_address (hostip.c:191)
>> ==29530== by 0x8083CD4: verboseconnect (url.c:2001)
>> ==29530== by 0x8085AFB: SetupConnection (url.c:3383)
>>
>> Here's a patch which seems to solve this problem for me. All curl
>> tests passed, except for test 506. I guess the failure of this test is
>> triggered by the calls to Curl_share_lock() and Curl_share_unlock() I
>> added around a "lonely" dns->inuse++ (these new calls were not needed
>> to solve my problem, but I guess they were missing. May be I'm wrong).
>
>
> Thanks for your work.
>
> Can you please enlighten me on what situation that causes this problem?
> Your fix seems to make the second call to the verboseconnect() function
> use the previous result. When is it calling this twice on the same
> connection? Or rather, why is the conn->ip_addr pointer not a fine
> pointer anymore? It is supposed to point to a addrinfo struct which
> shouldn't be free()d until the connection is closed.
>

You're right. The fix tries to use the previous result of
Curl_printable_address in verboseconnect(), instead of using
conn->ip_addr once again.

The problem is that the dns_entry in my application is shared with
another connection. When the dns_entry is older than 60 seconds and the
dns->inuse is zero it can be free()ed. But as conn->ip_addr shares data
with conn->dsn_entry, when the dns_entry is free()ed by another
completed connection, it makes conn->ip_addr invalid...

This fix is probably not the best way to fix this behaviour, but it has
been successful in my case.

> Or have I just had too little coffe?
>

Or may be I'm wrong and/or not explicit enough :-)
Received on 2004-09-22