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;
}
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);
}
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.