Psycopg psycopg → psycopg2 2.5.3

Comments and changes to this ticket

• You flagged this item as spam.
  

  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.

• You flagged this item as spam.
  

  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.