Re: pl/python tracebacks v2

From: Jan Urbański <wulczer(at)wulczer(dot)org>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pl/python tracebacks v2
Date: 2011-04-06 21:54:41
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 06/04/11 22:16, Jan Urbański wrote:
> On 06/04/11 21:38, Peter Eisentraut wrote:
>> On mån, 2011-03-21 at 00:40 +0100, Jan Urbański wrote:
>>> I finally got around to updating the PL/Python tracebacks patch. The
>>> other day I was writing some very simple PL/Python code and the lack of
>>> tracebacks is extremely annoying.
>> I tweaked this a bit to make the patch less invasive, and then committed
>> it. :)
> Ouch, just today I found a flaw in this, namely that it assumes the
> lineno from the traceback always refers to the PL/Python function. If
> you create a PL/Python function that imports some code, runs it, and
> that code raises an exception, PLy_traceback will get utterly confused.
> Working on a fix...

Here's the fix.

The actual bug was funny. The traceback code was fetching the file line
from the traceback and trying to get that line from the original source
to print it. But sometimes that line was refering to a different source
file, like when the exception originated from an imported module.

In my testing I accidentally had the error (in a separate module) on
line 2, so the traceback code tried to fetch line 2 of the function,
which was completely whitespace. This can never happen in theory,
because you can't have a frame starting at an all-whitespace line. The
code to get that line was misbehaving and trying to do a malloc(-2),
which in turn was causing an "ERROR invalid memory allocation".

All that is fixed with the attached patch.


PS: and thanks for committing that in the first place! :)


Attachment Content-Type Size
plpython-traceback-bug.patch text/x-patch 3.7 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message A.M. 2011-04-06 22:08:35 Re: lowering privs in SECURITY DEFINER function
Previous Message Robert Haas 2011-04-06 21:48:37 Re: postgresql.conf error checking strategy