Re: Potential reference miscounts and segfaults in plpython.c - Mailing list pgsql-hackers

From Jan Urbański
Subject Re: Potential reference miscounts and segfaults in plpython.c
Date
Msg-id 4F418F20.9000803@wulczer.org
Whole thread Raw
In response to Re: Potential reference miscounts and segfaults in plpython.c  (Jan Urbański <wulczer@wulczer.org>)
Responses Re: Potential reference miscounts and segfaults in plpython.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Potential reference miscounts and segfaults in plpython.c  (Daniele Varrazzo <daniele.varrazzo@gmail.com>)
List pgsql-hackers
On 18/02/12 21:18, Jan Urbański wrote:
> On 18/02/12 21:17, Tom Lane wrote:
>> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <wulczer@wulczer.org> writes:
>>> On 18/02/12 20:30, Tom Lane wrote:
>>>> Dave Malcolm at Red Hat has been working on a static code analysis tool
>>>> for Python-related C code.  He reports here on some preliminary results
>>>> for plpython.c:
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=795011
>>
>> If you find any live bugs, it'd likely be better to deal with them as
>> a separate patch so that we can back-patch ...
>
> Sure, I meant to say I'll look at these as well, but will make them into
> a separate patch.

Here's a patch that fixes everything I was sure was an actual bug. The
rest of the warnings seem to be caused by the tool not knowing that
elog(ERROR) throws a longjmp and things like "we never unref this
object, so it can't disappear mid-execution".

Attached are patches for HEAD and for 9.1.x (since splitting plpython.c
in 9.2 was kind of my idea I felt bad about you having to back-patch
this so I tried to do the necessary legwork myself; I hope the attached
is what you need).

BTW, that tool is quite handy, I'll have to try running it over psycopg2.

Cheers,
Jan

Attachment

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: 16-bit page checksums for 9.2
Next
From: Jan Urbański
Date:
Subject: Re: pl/python long-lived allocations in datum->dict transformation