Daniel Stenberg wrote:
> On Fri, 9 Sep 2005, Jonathan Cobb wrote:
>
>> I'm writing an apache module that uses libcurl internally. We're
>> using the latest libcurl (1.14.1)
>
>
> I assume that's a typo and you mean 7.14.1.

Yes, that was a typo.

>> Somehow, the "data" pointer is null. I added
>> if (!data || ...)
>> to the first "if" check and I'm thinking this will make it go away.
>
>
> It might hide the problem for you, but I would guess you'll get a crash
> elsewhere instead. See below.

Yup, that "fix" still resulted in a segfault, somewhere else.

> Calling the cleanup twice might cause something like that, or possibly
> if memory is overwritten either by your app or by libcurl itself.
>
> I have not seen any similar bug getting reported nor have this area of
> the code been modified in a long while.

A thought -- could this be caused by opening a CURL handle with
curl_easy_init, then calling curl_easy_reset (possibly multiple times)?
  I'm guessing that curl_easy_reset is safe to call multiple times and
would not reset the data pointer, but I thought I'd ask.

I've switched the allocation of the CURL handle from the request pool to
the connection pool. The idea is that Apache will sometimes reuse a
single TCP connection across multiple requests (to support http
keepalives).

I'm thinking maybe the request cleanup is getting called multiple times
(even though there should be separate request pools for each request),
and the connection cleanup will only be called once (though now there
will be multiple CURL handles in the pool to cleanup). It might be a
long shot, but I'll see if that fixes things.

   - jonathan.
Received on 2005-09-10