Hi =^-^=

In our project, we're getting memory leak reports from our crash report system at program shutdown of our Windows builds. The leak is that connssl->cred in curl_schannel.c is not being freed.

We're using the "multi" mode, since we may have several downloads happening at once, and we have asynchronous event dispatching on a thread. We don't think that it's our code's fault--though we can't eliminate that possibility, of course--because we don't see equivalent reports of leaks from curl_darwinssl.c on our Mac builds or whatever the OpenSSL equivalent is on our Linux builds.

We can't reproduce this ourselves; only end users are seeing this problem. It's fairly rare, though, which makes me suspect that it's an error handling problem, or a shutdown timing problem.

We've looked at the code a bit lately and don't really know enough about the state machine to fully determine why it might leak. The caching mechanism makes it complicated.

I know that this is not much information to go on, but if there is something more you'd like to know about it, let me know and I'll see what I can do.

By the way, I had to come up with a cute hack to figure out where the leak was coming from. It wasn't straightforward to modify libcurl to redirect all allocations to our application in a way that told our application the filename and line number within libcurl that was requesting the memory. I was able to pull it off without changing any libcurl source, which is always nice--patching open-source code makes it difficult when the next version of that library is released. (I used tricks with #include directory ordering and doing #define HEADER_CURL_MEMORY_H from my own header. I suppose that that's one advantage that old-style #include guards have over #pragma once. =^-^=)

(Yes, I know that #pragma once is non-standard, which I assume is why curl doesn't use it. =) )

Thanks,

Melissa
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-10-01