Yes, we know where the leak is. After I made a hack to get libcurl to export its filename and line number information to us (harder than it looks), I got it down to this line:

/* allocate memory for the re-usable credential handle */
connssl->cred = malloc(sizeof(struct curl_schannel_cred));
if(!connssl->cred) {
  failf(data, "schannel: unable to allocate memory");
  return CURLE_OUT_OF_MEMORY;
}

The problem is tracking down why the memory isn't freeing correctly, due to the way that this memory block is cached. We have never seen the leak occur ourselves--we have only ever seen this as reports from our automated crash logger (which also reports memory leaks).

Melissa

---- Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Wed, 8 Oct 2014, myriachan_at_cox.net wrote:

> Unfortunately, we are still seeing this occur even after merging this fix.
> I definitely agree about the reference counting being difficult to track.

Don't you have any tool or method that can tell you exactly which allocation
it is that leaks?

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html