Re: plpython crash (PG 92)
От | Peter Eisentraut |
---|---|
Тема | Re: plpython crash (PG 92) |
Дата | |
Msg-id | 1335558256.29985.8.camel@vanquo.pezone.net обсуждение исходный текст |
Ответ на | plpython crash (PG 92) (Asif Naeem <asif.naeem@enterprisedb.com>) |
Ответы |
Re: plpython crash (PG 92)
Re: plpython crash (PG 92) |
Список | 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.
В списке pgsql-hackers по дате отправления: