This project is archived and is in readonly mode.
assertion failed in pqpath.c
Reported by Edouard Chamillard | December 24th, 2013 @ 03:32 PM | in psycopg2 2.5.3 (closed)
rel-2.5.1 os-linux
celery tasks are using psycopg through sqlalchemy from two
different machines. on one it works fine, on the other it
segfaults. after a bit of digging a recompiling stuff with debug
enabled i got
[5538] pq_execute: entering synchronous DBAPI compatibility mode
[5538] pq_fetch: pgstatus = PGRES_TUPLES_OK
[5538] pq_fetch: got tuples
[5538] pq_fetch_tuples: looking for cast 26:
[5538] curs_get_cast: per-connection dict: (nil)
[5538] curs_get_cast: global dict: 0x7f3b18ad0628
python3.3: psycopg/pqpath.c:1139: _pq_fetchtuples: Assertion `((((((PyObject*)(((typecastObject*)cast)->name))->ob_type))->tp_flags & ((1L<<27))) != 0)' failed.
Aborted (core dumped)
full trace attached.Comments and changes to this ticket
-
Edouard Chamillard December 24th, 2013 @ 03:33 PM
for reference this is the relevant pqpath.c code block
/* else if we got binary tuples and if we got a field that is binary use the default cast FIXME: what the hell am I trying to do here? This just can't work.. */ if (pgbintuples && cast == psyco_default_binary_cast) { Dprintf("_pq_fetch_tuples: Binary cursor and " "binary field: %i using default cast", PQftype(curs->pgres,i)); cast = psyco_default_cast; }
-
Daniele Varrazzo January 7th, 2014 @ 04:38 PM
- State changed from new to open
I've not been able to reproduce the issue, although I've run psycopg test suite againts Python 3.3.
I don't think the block you have reported is the correct one. The one to blame looks:
Dprintf("_pq_fetch_tuples: using cast at %p (%s) for type %d", cast, Bytes_AS_STRING(((typecastObject*)cast)->name), PQftype(curs->pgres,i)); Py_INCREF(cast); PyTuple_SET_ITEM(casts, i, cast);
there is indeed some sort of error as running
cur.execute("select 1")
in Python 3.3 64 bit I see[12119] pq_execute: entering synchronous DBAPI compatibility mode [12119] pq_fetch: pgstatus = PGRES_TUPLES_OK [12119] pq_fetch: got tuples [12119] _pq_fetch_tuples: looking for cast 23: [12119] curs_get_cast: per-connection dict: (nil) [12119] curs_get_cast: global dict: 0x7f4b035edb50 [12119] _pq_fetch_tuples: using cast at 0x7f4b035edb50 (�) for type 23 [12119] pq_fetch: fetching done; check for critical errors [12119] psyco_curs_execute: res = 1, pgres = 0x1929ce0
the ? at "using cast" is probably the result of a bad dereferencing; probably you are running it in a debug version of python with asserts enabled.
I think the above idiom is broken for all Python 3. Mmm... too bad I've overlooked the issue and just released.
-
Edouard Chamillard January 7th, 2014 @ 04:47 PM
the trace was indeed produced by a debug version of python. originally gdb pointed to pqpath.c:1140 which is Py_INCREF(cast);
i can try to reproduce the issue and link the whole coredump if you need.
-
Daniele Varrazzo January 7th, 2014 @ 05:12 PM
A script to reproduce the issue would be preferred. A patch to fix the issue would be even better accepted, above all if checking the issue implies recompiling python in debug mode. You'd save me quite some time.
I've not understood yet what is the problem though. The problem in the Dprintf is probably just that the name is an unicode object under Py3. But why the incref should fail?
curs_get_cast()
doesn't seem able to return NULL. -
Daniele Varrazzo March 10th, 2014 @ 05:25 PM
- Milestone set to psycopg2 2.5.3
-
Daniele Varrazzo April 4th, 2014 @ 06:31 PM
- State changed from open to resolved
Fixed in master and maint_2_5. As I expected it was the bad use of Bytes_AS_STRING causing the assertion failure. Tested on a debug build Py3.4. Also found an unrelated bug exposed by debug build, so good stuff.
If you can test everything works in your environment it would be great, thank you.
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป
<b>WARNING:</b> the informations in this tracker are archived. Please submit new tickets or comments to <a href="https://github.com/psycopg/psycopg2/issues">the new tracker</a>.
<br/>
Psycopg is the most used PostgreSQL adapter for the Python programming language. At the core it fully implements the Python DB API 2.0 specifications. Several extensions allow access to many of the features offered by PostgreSQL.