On 12/02/11 10:00, Alex Hunsaker wrote: > On Sat, Feb 12, 2011 at 01:50, Jan Urbański <wulc...@wulczer.org> wrote: >> On 12/02/11 04:12, Alex Hunsaker wrote: >>> In PLy_traceback fname and prname look like they will leak (well as >>> much as a palloc() in an error path can leak I suppose). >> >> But they're no palloc'd, no? fname is either a static "<module"> string, >> or PyString_AsString, which also doesn't allocate memory, AFAIK. > > Yeah, I was flat out wrong about proname :-(. > > As for fname, I must be missing some magic. We have: > > #if PY_MAJOR_VERSION > 3 > ... > #define PyString_AsString(x) PLyUnicode_AsString(x) > .... > PLyUnicode_AsString(PyObject *unicode) > { > PyObject *o = PLyUnicode_Bytes(unicode); > char *rv = pstrdup(PyBytes_AsString(o)); > > Py_XDECREF(o); > return rv; > } > > PyString_AsString is used all over the place without any pfrees. But I > have no Idea how that pstrdup() is getting freed if at all. > > Care to enlighten me ?
Ooops, seems that this hack that's meant to improve compatibility with Python3 makes it leak. I wonder is the pstrdup is necessary here, but OTOH the leak should not be overly significant, given that no-one complained about it before... and PyString_AsString is being used in several other places. Jan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers