It was in the parseHeaders() routine from the previous post. It is kind of obvious now, I must have placed my faith in some impossible API voodoo:

    // extract field name
        if (state == NAME) {
            if (sscanf(str, "%[^:]:", copy) != 1) break;    // malform
+ed
            lowerCase(copy);
            cur = hv_fetch(hdrs, copy, strlen(copy), 1);
            if (!SvOK(*cur)) *cur = newSVpv("", 0);
            state = VALUE;
            continue;
        }
[download]

Setting the last arg to hv_fetch will create a key-value pair if it does not exist already and return a pointer to the value pointer, a newSV(0) (ie, undef, so !SvOK means the key is new). Since I wanted to concat multiple entries for the same header field into a CSV string, I reassigned a newSVpv("") to the pointer pointer, leaking the undef SV it pointed to. Changing to this:

            cur = hv_fetch(hdrs, copy, strlen(copy), 1);
            if (!SvOK(*cur)) {
                SvREFCNT_dec(*cur);
                *cur = newSVpv("", 0);
            }
[download]

Fixed the leak...probably the reason I didn't see this issue at first is because the API has no "free" functions, it relies on reference counts. But I put my money on voodoo (if you aren't sure what to do, don't do anything, lol).

I found this by checking PL_sv_count before and after function calls. parseHeaders() returns a hash of headers, but after the call PL_sv_count was incremented by 2 (one for the hash, one for the ref it is assigned to in parseRequest()) + twice as many keys as were actually in the hash.