From: | Kevin Houle <kjh(at)cert(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: DBD::Pg 'lo_read' fails on >= 32768 byte large objects |
Date: | 2003-08-15 17:35:12 |
Message-ID: | 5080000.1060968912@discus.blue.cert.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
--On Friday, August 15, 2003 08:43:23 AM -0400 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
wrote:
> Kevin Houle <kjh(at)cert(dot)org> writes:
>> The nature of the bug is that an 'lo_read' operation performed
>> with DBD::Pg caused a segfault with postgresql-libs-7.3.2 and
>> "hangs" on files >= 32768 bytes with postgresql-libs-7.3.4. The
>> hang is actually a read() loop on the socket generating EAGAIN
>> error on each read().
>
> Can you get us a gdb stack trace from the segfault cases? (And from
> the loop cases too; a stack trace back from the repeated read() call
> would be useful.)
The attached gdb-7.3.2.log is from the segfault case using
postgresql-libs-7.3.2 and the gdb-7.3.4.log is the loop case
from postgresql-libs-7.3.4. I had to SIGINT the loop case to
get the stack trace.
> Also, does adding/removing SSL encryption affect your results?
Yes. It works flawlessly without SSL. I thought I had tested that
previously but in fact did not correctly; I re-tested and it works
without SSL and fails with SSL. The stack traces seem to point to
pqsecure_read().
Let me know if I can provide anything else.
Kevin
Attachment | Content-Type | Size |
---|---|---|
gdb-7.3.2.log | application/octet-stream | 3.7 KB |
gdb-7.3.4.log | application/octet-stream | 2.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-08-15 18:09:32 | Re: DBD::Pg 'lo_read' fails on >= 32768 byte large objects |
Previous Message | Tom Lane | 2003-08-15 12:43:23 | Re: DBD::Pg 'lo_read' fails on >= 32768 byte large objects |