I've been trying to figure out where a memory leak in the pycurl
bindings on Fedora is coming from and how to resolve it. Kamil Dudka
has been doing work here as well::
  http://curl.haxx.se/mail/lib-2009-03/0019.html

From reading that thread, I think the current thought is that this is a
leak caused by incorrectly using the libcurl API. I have a simple test
case that I want to run by you to see what the right use of the API is::

/* BEGIN */
#include <curl/curl.h>
#include <stdio.h>

void do_nothing(void *data) {
;
}

int main() {
    CURL *c;
    int i;

    curl_global_init(CURL_GLOBAL_ALL);
    for (i = 1; i < 200; i++) {
        printf("%d ", i);
        fflush(stdout);
        c = curl_easy_init();

        curl_easy_setopt(c, CURLOPT_URL,
                "https://admin.fedoraproject.org/accounts");
        curl_easy_setopt(c, CURLOPT_WRITEFUNCTION, do_nothing);
        curl_easy_perform(c);

        curl_easy_cleanup(c);

        printf("%d\n", i);
        fflush(stdout);
        /* If I use this, no leak occurs
         * curl_global_cleanup();
         */
    }
    curl_global_cleanup();
    return 0;
}
/* END*/

When I compile and run this using our nss linked libcurl, I leak memory.
 When I uncomment the inner curl_global_cleanup() I don't leak memory.

Is using the inner curl_global_cleanup the correct behavior? (Seems
wrong given the documentation and non-threadsafe nature of
curl_global_cleanup).

Is there something besides curl_easy_cleanup() I should be calling to
release memory from the CURL easy handle?

I'm guessing this is a bug in the libcurl+nss or nss library but I'd
like to know my test case is fine before launching into that code.

-Toshio