cURL / Mailing Lists / curl-library / Single Mail


Re: segfault in Curl_hostcache_prune

From: Daniel Stenberg <>
Date: Fri, 9 Sep 2005 23:33:22 +0200 (CEST)

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

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

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:
Received on 2005-09-09