Skip site navigation (1) Skip section navigation (2)

Re: plpython crash (PG 92)

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Asif Naeem <asif(dot)naeem(at)enterprisedb(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: plpython crash (PG 92)
Date: 2012-04-27 20:24:16
Message-ID: 1335558256.29985.8.camel@vanquo.pezone.net (view raw or flat)
Thread:
Lists: pgsql-hackers
On tor, 2012-04-26 at 17:32 +0500, Asif Naeem wrote:
> PFA test case. It used simple select statement to retrieve data via
> plpython. It crashes latest pg 9.2 with the following stack trace i.e.

> Apparently it is being crashed because of invalid related pointer value of
> pfree() *header->context->methods->free_p. It is reproducible with latest
> version of python i.e. Python-2.7.3 and Python-3.2.3. Thanks.

This is because of this code:

static void
PLy_result_dealloc(PyObject *arg)
{
    PLyResultObject *ob = (PLyResultObject *) arg;

    Py_XDECREF(ob->nrows);
    Py_XDECREF(ob->rows);
    Py_XDECREF(ob->status);
    if (ob->tupdesc)
    {
        FreeTupleDesc(ob->tupdesc);  // <-- dies here
        ob->tupdesc = NULL;
    }

    arg->ob_type->tp_free(arg);
}

I must have been confused about the tuple descriptor APIs.  ob->tupdesc
is created using CreateTupleDescCopy(), which copies the refcount of the
original tuple descriptor, thus causing a failure when the (seemingly
still referenced) tupdesc is freed.  Is this behavior correct and
useful?

The dominant coding practice appears to be to not explicitly free copied
tuple descriptors, so maybe that should be done here as well.


In response to

Responses

pgsql-hackers by date

Next:From: Andres FreundDate: 2012-04-27 20:30:10
Subject: Re: smart shutdown at end of transaction (was: Default mode for shutdown)
Previous:From: Peter EisentrautDate: 2012-04-27 20:17:59
Subject: Re: smart shutdown at end of transaction (was: Default mode for shutdown)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group