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.

> Sometimes (infrequently and difficult to reproduce), a segfault occurs in
> the cleanup. The backtrace is below, at the end of this message.
>
> The segfault is caused by dereferencing a null pointer, in the
> Curl_hostcache_prune function (in hostip.c):

...

> 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.

> But I'm wondering if this is the right thing to do. Under what conditions
> would this pointer be null? Also, I have a suspicion that maybe our cleanup
> is getting called twice - if that were the case, could that cause the data
> pointer to be null?

Let me first quickly describe how the two main structs within libcurl are
related.

There's the SessionHandle struct. That is the main one, which is returned as a
handle in the curl_easy_init() function. This struct will always be around as
long as there is an easy handle (CURL *). This pointer is always called 'data'
in the code.

Within the 'data' struct, there is a list of 'struct connectdata'. One such
for each connection this SessionHandle keeps alive (usually the max amount is
5).

Within the connectdata struct, there's a pointer called 'data' that points
back to the "parent" SessionHandle struct. Thus, this pointer can never
legally be NULL and will always point to a valid struct.

In the backstrace you showed, the 'data' member within the connectdata struct
obviously was NULL when used within Curl_disconnect(). That simply shouldn't
happen. It shows a major error has occurred already then.

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.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html