Re: pl/python tracebacks

From: Jan Urbański <wulczer(at)wulczer(dot)org>
To: Alex Hunsaker <badalex(at)gmail(dot)com>
Cc: Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pl/python tracebacks
Date: 2011-02-12 09:07:09
Message-ID: 4D564DBD.4070108@wulczer.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/02/11 10:00, Alex Hunsaker wrote:
> On Sat, Feb 12, 2011 at 01:50, Jan Urbański <wulczer(at)wulczer(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alex Hunsaker 2011-02-12 09:18:36 Re: [COMMITTERS] pgsql: Force strings passed to and from plperl to be in UTF8 encoding.
Previous Message Alex Hunsaker 2011-02-12 09:00:30 Re: pl/python tracebacks