Обсуждение: segmentation faults with psycopg2 and multiprocessing

Hello:

I am using psycopg2 and multiprocessing (and have been for quite some
time). However, my application recently needed a connection to a new
database. After adding this connection, I am receiving segmentation
faults back in the parent process. I do not use the original connections
in the child process. I create new database connections in the children.
Does anyone have any idea about what the problem might be here?

-Ryan Kelly

On Fri, Sep 28, 2012 at 8:01 PM, Ryan Kelly <rpkelly22@gmail.com> wrote:
> Hello:
>
> I am using psycopg2 and multiprocessing (and have been for quite some
> time). However, my application recently needed a connection to a new
> database. After adding this connection, I am receiving segmentation
> faults back in the parent process. I do not use the original connections
> in the child process. I create new database connections in the children.
> Does anyone have any idea about what the problem might be here?

Can you produce a traceback?

-- Daniele

On Fri, Sep 28, 2012 at 08:20:49PM +0100, Daniele Varrazzo wrote:
> On Fri, Sep 28, 2012 at 8:01 PM, Ryan Kelly <rpkelly22@gmail.com> wrote:
> > Hello:
> >
> > I am using psycopg2 and multiprocessing (and have been for quite some
> > time). However, my application recently needed a connection to a new
> > database. After adding this connection, I am receiving segmentation
> > faults back in the parent process. I do not use the original connections
> > in the child process. I create new database connections in the children.
> > Does anyone have any idea about what the problem might be here?
>
> Can you produce a traceback?
With GDB? I've attached one. To me, it doesn't look very useful. Maybe
I'm doing something wrong?

-Ryan Kelly

On Fri, Sep 28, 2012 at 08:20:49PM +0100, Daniele Varrazzo wrote:
> On Fri, Sep 28, 2012 at 8:01 PM, Ryan Kelly <rpkelly22@gmail.com> wrote:
> > Hello:
> >
> > I am using psycopg2 and multiprocessing (and have been for quite some
> > time). However, my application recently needed a connection to a new
> > database. After adding this connection, I am receiving segmentation
> > faults back in the parent process. I do not use the original connections
> > in the child process. I create new database connections in the children.
> > Does anyone have any idea about what the problem might be here?
>
> Can you produce a traceback?
Or maybe this new one is better?

-Ryan Kelly

On Fri, Sep 28, 2012 at 10:03 PM, Ryan Kelly <rpkelly22@gmail.com> wrote:

>> Can you produce a traceback?
> Or maybe this new one is better?

They are both fine, I can see the error is during a rollback, in the
Python API call that queries whether there is a Python exception set.
Just... it doesn't make sense: the only way that function may bomb, I
think, is when we call it without holding the GIL, and it is actually
acquired the line above.

Reading again you original post: you connect from the children and the
parent crashes? I think I'm reading it wrong... Also, what do you mean
that "you have added a connection": the app was already using psycopg
and you are now connecting to a new database too?

Ritual questions: what psycopg, postgres and python versions are?

Are you using any "magic": greenlet, signals, threads, apart from processing?

The rollback issued looks called from Python, not internally. Does
your program call conn.rollback() in some strange situation, such as
in an object __del__ or at application cleanup?

A last useful piece of info: could you compile psycopg with debug info
on (see setup.cfg) and run it with the info (set the env var
PSYCOPG_DEBUG before running the program)? We may find something in
the logs.

Thank you.

-- Daniele

On Fri, Sep 28, 2012 at 10:27:03PM +0100, Daniele Varrazzo wrote:
> On Fri, Sep 28, 2012 at 10:03 PM, Ryan Kelly <rpkelly22@gmail.com> wrote:
>
> >> Can you produce a traceback?
> > Or maybe this new one is better?
>
> They are both fine, I can see the error is during a rollback, in the
> Python API call that queries whether there is a Python exception set.
> Just... it doesn't make sense: the only way that function may bomb, I
> think, is when we call it without holding the GIL, and it is actually
> acquired the line above.
>
> Reading again you original post: you connect from the children and the
> parent crashes? I think I'm reading it wrong... Also, what do you mean
> that "you have added a connection": the app was already using psycopg
> and you are now connecting to a new database too?
I have connections open in the parent process. I fork via
multiprocessing. I open new connections for use in the children. When
control returns to the parent, I attempt to execute a query, and at that
point I get a segmentation fault.

> Ritual questions: what psycopg, postgres and python versions are?
psycopg2: 2.4.2
postgres: 9.1.2
python: 2.7.1+

> Are you using any "magic": greenlet, signals, threads, apart from processing?
Nope. Not that I know of anyway.

> The rollback issued looks called from Python, not internally. Does
> your program call conn.rollback() in some strange situation, such as
> in an object __del__ or at application cleanup?
Presumably sqlalchemy is calling ROLLBACK on error.

> A last useful piece of info: could you compile psycopg with debug info
> on (see setup.cfg) and run it with the info (set the env var
> PSYCOPG_DEBUG before running the program)? We may find something in
> the logs.
Will do.

>
> Thank you.
>
> -- Daniele

-Ryan Kelly

On Fri, Sep 28, 2012 at 10:43 PM, Ryan Kelly <rpkelly22@gmail.com> wrote:

>> Ritual questions: what psycopg, postgres and python versions are?
> psycopg2: 2.4.2

Oh, there it is: it's a known issue, it has been fixed in 2.4.3. I've
missed it at a first scan of the git blame, but we were actually not
reacquiring the GIL before calling PyErr_Occurred().

Just bump to the latest psycopg version and everything should be fixed.

-- Daniele

On Fri, Sep 28, 2012 at 11:48:54PM +0100, Daniele Varrazzo wrote:
> On Fri, Sep 28, 2012 at 10:43 PM, Ryan Kelly <rpkelly22@gmail.com> wrote:
>
> >> Ritual questions: what psycopg, postgres and python versions are?
> > psycopg2: 2.4.2
>
> Oh, there it is: it's a known issue, it has been fixed in 2.4.3. I've
> missed it at a first scan of the git blame, but we were actually not
> reacquiring the GIL before calling PyErr_Occurred().
>
> Just bump to the latest psycopg version and everything should be fixed.
This is great news. Thanks!

>
> -- Daniele

-Ryan Kelly