Ragnar,
I agree with you that it should be done by libcurl. Probably in the
cleanup functions. However, it appears that one of the engines has not
been freed. If you check the earlier posts in this thread (posted in
December 2008), you will find that Dan ran a simple libcurl program in
Valgrind and revealed memory leak that is due to an ENGINE_new call.
So for that particular call, it appears that no matching ENGINE_free
has been called. As for my previous post, I was referring to a quick
fix that a libcurl user could do in case he has access to ENGINE
pointers called by libcurl. But I definitely agree that the best fix
is for libcurl to free all those ENGINEs that were allocated.

- Huzaifa

On Mon, Jan 5, 2009 at 4:36 PM, Ragnar Lonn <ragnar_at_gatorhole.com> wrote:
> Huzaifa Al Nahas wrote:
>>
>> Dan,
>> After more research, it appears that it is a bug in libcurl design. I
>> contacted openssl support team and they replied suggesting that the
>> memory leak can be avoided by using ENGINE_free. However, this
>> function takes as argument a pointer to the ENGINE that was called in
>> ENGINE_new. AFAIK libcurl does not give the library user access to
>> this pointer. What do you think?
>>
>
> I'm fairly new to libcurl, but it would seem very strange if you as a user
> had to call ENGINE_free() to clean up after libcurl's SSL engine. A quick
> look at the source shows also that libcurl does call ENGINE_free(), so I
> don't think it is something the libcurl user has to bother with. I think
> you're on the wrong track, but if you suspect that ENGINE_free() is not
> called, run it in a debugger and see what happens.
>
> raglon_at_snik1:~/curl-7.19.2$ grep ENGINE_free lib/*.c
> lib/ssluse.c: ENGINE_free(data->state.engine);
> lib/ssluse.c: ENGINE_free(e);
> lib/ssluse.c: ENGINE_free(data->state.engine);
>
> /Ragnar
>
Received on 2009-01-06