Re: SIGSEGV in psycopg2 2.0.14 (and 2.2.0rc1)

On 04/05/10 14:30, Grzegorz Aksamit wrote:
> Hi,

Hi,

> I'm having problems with psycopg2 crashing at random places with null
> pointer reference. It crashes after few minutes of intensive use
> (around two queries per second). The crash does not depend on query
> itself, as it crashes on all of them. It looks more like some threads
> related race condition.

Could you provide a Python script that reproduces the problem? Ideally
with a simplest possible database dump that leads to the crash. I did a
quick test with a couple of threads and heavy SELECT traffic and it
worked fine. There must be something atypical about your usage pattern,
because otherwise the problem would have been noticed earlier.

> Here's the backtrace from gdb:
> 
> Program received signal SIGSEGV, Segmentation fault.
(snip)
> #0  strlen () at ../sysdeps/i386/i486/strlen.S:69
> #1  0x0809f3ca in PyString_FromString ()
> #2  0xb79e63c9 in _pq_fetch_tuples (curs=0x837de9c) at psycopg/pqpath.c:826

This most probably means that PQfname returned NULL which then has been
passed to PyString_FromString, which died. Docs say that PQfname can
return NULL if the column number is out of range, but since the code is
doing a loop over 0..n where n is the result of PQnfields, and all this
is done while holding the connection mutex, I can't see how this could
have happened.

Could you, just to verify, look at the pointer passed to strlen() in the
last frame? Also, in frame #2, could you check the values of the
pgnfields and i local variables?

> #3  pq_fetch (curs=0x837de9c) at psycopg/pqpath.c:1215
> #4  0xb79e79aa in pq_execute (curs=0x837de9c,
>     query=0x84503e4 "select
> u.user_id,u.group_id,s.rank,s.last_sec_id,extract(epoch from
> max_timestamp(s.last_position_time,max_timestamp(s.last_login_time,s.last_logout_time))),extract(epoch
> from s.ban_stop_time),s.banne"..., async=0)
>     at psycopg/pqpath.c:706

Also, could you tell how many columns that query was supposed to return?

> AFAIK the problems could be caused by libpq compiled without
> --with-thread-safety - I'm using debian sid libpq5 8.4.1-1 package.
> I'm not sure, but it should be compiled with thread safety option
> enabled.

I think Debian compiles all of postgres with thread safety. Run
pg_config --configure just in case.

> Can somebody help me with this issue? It makes my code completely
> useless under heavy load.

A reproducible test case would go a long way...

Cheers,
Jan