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

From Robert Haas
Subject Re: Potential reference miscounts and segfaults in plpython.c
Date
Msg-id CA+TgmoZzk1JNwAGsDH9ohnz0O7j3a=K0U+YOXKViHB1imNNKZg@mail.gmail.com
Whole thread Raw
In response to Re: Potential reference miscounts and segfaults in plpython.c  (Jan Urbański <wulczer@wulczer.org>)
List pgsql-hackers
On Mon, Feb 20, 2012 at 5:05 AM, Jan Urbański <wulczer@wulczer.org> wrote:
> On 20/02/12 04:29, Tom Lane wrote:
>> Jan Urbański <wulczer@wulczer.org> writes:
>>>> On 18/02/12 21:17, 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
>>
>>> 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".
>>
>> My only comment is whether elog(ERROR) is appropriate, ie, do we consider
>> these to be internal errors that users will never see in practice?
>
> AFAICS these errors can only happen on out of memory conditions or other
> internal errors (like trying to create a list with a negative length).

We typically want out of memory to use ereport, so that it gets
translated.  For example, in fd.c we have:
               ereport(FATAL,                               (errcode(ERRCODE_OUT_OF_MEMORY),
   errmsg("out of memory"))); 

Trying to create a list with a negative length sounds similar.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Itagaki Takahiro
Date:
Subject: array_to_json re-encodes ARRAY of json type
Next
From: Robert Haas
Date:
Subject: Re: 16-bit page checksums for 9.2