On Tue, 22 Aug 2006, Plamen Barzakov wrote:

> I am building a program using libcurl 7.15.3 and I get that message at a
> certain point:
>
> *** glibc detected *** free(): invalid pointer: 0x08066f24 ***
>
> Debuging the program shows that the program dies after a call to
> Curl_safefree();
> I played around with the debugger a little bit and got different results:
> the invalid pointer is conn->allocptr.host. Relinking the program with the
> library results in different behaviour: another free(); invalid pointer,
> this time when trying to free conn->proto.generic.

This makes it sound like there's "someone" that destroys the memory pool and
then random free() calls crash due to this. It is in fact likely that the
"someone" in this case is your own app.

Can you make a stand-alone application that repeats the problem using libcurl
7.15.5 and if so, provide the source code for that to the list? Did you try
using valgrind to track the origins of the problem?

> I didn't have time to browse the code responsible for allocating and setting
> those variables, but I found out that the implementation of Curl_safefree();
> is not that safe actually...

Safe from what? It does exactly what it is designed for.

> This is the way most of the people implement such "safe" functions for
> allocating and deallocating memory, but it's generally bad.

Thank you for educating us in good programming practises, but I disagree with
your conclusion.

> The reason is that if ptr does not point to an allocated memory, we never
> know if it's NULL or not.

We know that if it isn't NULL we should free it, and if it is NULL we should
not. That is amazingly enough why it is written like that!

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