Re: pl/python tracebacks

Поиск
Список
Период
Сортировка
От Alex Hunsaker
Тема Re: pl/python tracebacks
Дата
Msg-id AANLkTi=26HegqC67MB5ue3cEwJgwNeLCdtGB8H+Sbs9c@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pl/python tracebacks  (Jan Urbański <wulczer@wulczer.org>)
Ответы Re: pl/python tracebacks  (Jan Urbański <wulczer@wulczer.org>)
Re: pl/python tracebacks  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
On Sat, Feb 12, 2011 at 01:50, Jan Urbański <wulczer@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 ?


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jan Urbański
Дата:
Сообщение: Re: pl/python tracebacks
Следующее
От: Jan Urbański
Дата:
Сообщение: Re: pl/python tracebacks