Jim Gallacher <jpg <at> jgassociates.ca> writes:
>
> I've run some tests to evaluate the memory leaks. The tests are brute
> force - make requests and watch the memory changes with top -b.
>
...
> First up - our leaky 3.2.9, and man does it leak! The readlines request
> has a body of 1M bytes, and it fails in a hurry.
>
...
> Everything is looking much better, with readlines looking very stable.
> Cfgtree_walk and parse_qsl are also looking much better but there may
> still be a problem. To confirm this I ran the tests against 3.2.x build
> 20060709 again, but with 100,000 requests.
>
Did you have a chance to re-run the tests?
There are some things I've found, although I don't think they cause a leak.
For example, in parse_qs() there is:
pair = PyString_FromStringAndSize(NULL, len);
if (pair == NULL)
return NULL;
this should be:
pair = PyString_FromStringAndSize(NULL, len);
if (pair == NULL) {
Py_DECREF(pairs);
return NULL;
}
There are a few more like that in parse_qs() and parse_qsl(), and
cfgtree_walk().
In req_readlines(), line 810/811 the intention isn't clear of:
if (result == NULL)
return PyErr_NoMemory();
While the exact same code on lines 814/815 are not correct.
They should be:
if (rlargs == NULL) { // note rlargs not result
Py_DECREF(result);
return PyErr_NoMemory();
}
