Re: DBD::Pg 'lo_read' fails on >= 32768 byte large objects

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kevin Houle <kjh(at)cert(dot)org>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: DBD::Pg 'lo_read' fails on >= 32768 byte large objects
Date: 2003-08-15 18:09:32
Message-ID: 19712.1060970972@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Kevin Houle <kjh(at)cert(dot)org> writes:
>> Can you get us a gdb stack trace from the segfault cases?

> #36 0x40421712 in pqsecure_read () from /usr/lib/libpq.so.3
> #37 0x40421712 in pqsecure_read () from /usr/lib/libpq.so.3
> #38 0x40421712 in pqsecure_read () from /usr/lib/libpq.so.3
> #39 0x40421712 in pqsecure_read () from /usr/lib/libpq.so.3
> ...
> cut thousands of lines; you get the idea

In 7.3.2 pqsecure_read will recurse to self when SSL_read returns
SSL_ERROR_WANT_READ. I changed the recursion to a loop in 7.3.4.
Evidently, in 7.3.2 it's possible for the recursion to overflow your
alloted stack space before the process uses up its timeslice :-(.
In 7.3.4 the loop simply doesn't exit.

I don't understand why, though. What I expected would happen is that
the process would busy-wait until more data becomes available from the
connection. That's not ideal but the full fix seemed safer to postpone
to 7.4. Can you set up this situation, then attach with gdb to the
connected backend and see what it thinks it's doing? A stacktrace from
that side of the connection might shed some light.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Kevin Houle 2003-08-15 20:19:22 Re: DBD::Pg 'lo_read' fails on >= 32768 byte large objects
Previous Message Kevin Houle 2003-08-15 17:35:12 Re: DBD::Pg 'lo_read' fails on >= 32768 byte large objects