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

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 20:19:22
Message-ID: 8810000.1060978762@discus.blue.cert.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

--On Friday, August 15, 2003 02:09:32 PM -0400 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
wrote:

> 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'll consider 7.3.2 a bad choice.

> 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.

Okay. Here's stack traces from both sides, to put the information
in the same bucket. The gdb info on the client side...

(gdb) info stack
#0 0xffffe002 in ?? ()
#1 0x404dd242 in BIO_read () from /lib/libcrypto.so.4
#2 0x40455bf0 in ssl3_alert_code () from /lib/libssl.so.4
#3 0x40455d8c in ssl3_alert_code () from /lib/libssl.so.4
#4 0x4045705e in ssl3_read_bytes () from /lib/libssl.so.4
#5 0x40454619 in ssl3_write () from /lib/libssl.so.4
#6 0x404546a7 in ssl3_read () from /lib/libssl.so.4
#7 0x4045cd2b in SSL_read () from /lib/libssl.so.4
#8 0x404216d1 in pqsecure_read () from /usr/lib/libpq.so.3
#9 0x4041d76a in pqReadData () from /usr/lib/libpq.so.3
#10 0x4041c224 in PQfn () from /usr/lib/libpq.so.3
#11 0x4041f773 in lo_read () from /usr/lib/libpq.so.3
#12 0x4014c194 in pg_db_lo_read (dbh=0xfffffff5, fd=5,
buf=0x5 <Address 0x5 out of bounds>, len=5) at dbdimp.c:545
#13 0x40144881 in XS_DBD__Pg__st_bind_param_inout (my_perl=0x804bcb8,
cv=0x81b1794) at Pg.xs:282
#14 0x40400247 in XS_DBI_dispatch (my_perl=0x804bcb8, cv=0x8187ee0)
at DBI.xs:2320
#15 0x400a34e5 in Perl_pp_entersub (my_perl=0x804bcb8) at pp_hot.c:2781
#16 0x40086c9a in Perl_runops_debug (my_perl=0x804bcb8) at dump.c:1414
#17 0x4003a9ab in S_run_body (my_perl=0x804bcb8, oldscope=-11) at
perl.c:1705
#18 0x4003a635 in perl_run (my_perl=0x804bcb8) at perl.c:1624
#19 0x080493a3 in main ()
#20 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6

(gdb) info reg
eax 0xfffffff5 -11
ecx 0x81cc880 136104064
edx 0x5 5
ebx 0x3 3
esp 0xbfffeaa4 0xbfffeaa4
ebp 0xbfffeac8 0xbfffeac8
esi 0x0 0
edi 0x81cc880 136104064
eip 0xffffe002 0xffffe002
eflags 0x246 582
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x33 51

And here is the gbd info from the attached backend process.

(gdb) info stack
#0 0xffffe002 in ?? ()
#1 0x400d5242 in BIO_read () from /lib/libcrypto.so.4
#2 0x4004dbf0 in ssl3_alert_code () from /lib/libssl.so.4
#3 0x4004dd8c in ssl3_alert_code () from /lib/libssl.so.4
#4 0x4004f05e in ssl3_read_bytes () from /lib/libssl.so.4
#5 0x4004c619 in ssl3_write () from /lib/libssl.so.4
#6 0x4004c6a7 in ssl3_read () from /lib/libssl.so.4
#7 0x40054d2b in SSL_read () from /lib/libssl.so.4
#8 0x080eff16 in secure_read ()
#9 0x080f43d2 in StreamClose ()
#10 0x080f4495 in pq_getbyte ()
#11 0x0813a194 in HandleFunctionRequest ()
#12 0x0813a21a in HandleFunctionRequest ()
#13 0x0813b8ba in PostgresMain ()
#14 0x0811f37b in ClosePostmasterPorts ()
#15 0x0811ee03 in ClosePostmasterPorts ()
#16 0x0811dc09 in PostmasterMain ()
#17 0x0811d3a6 in PostmasterMain ()
#18 0x080f5113 in main ()
#19 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6

(gdb) info reg
eax 0xfffffe00 -512
ecx 0x8282740 136849216
edx 0x5 5
ebx 0x8 8
esp 0xbfffe0b4 0xbfffe0b4
ebp 0xbfffe0d8 0xbfffe0d8
esi 0x0 0
edi 0x8282740 136849216
eip 0xffffe002 0xffffe002
eflags 0x246 582
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x33 51

Is it just me, or are both sides reading waiting for the other
side to send data?

Kevin

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Christoph Becker 2003-08-15 20:54:11 7.4beta1, Error in dumpall from 7.3.4 since CASCADE could not be used in REVOKE in 7.3.4
Previous Message Tom Lane 2003-08-15 18:09:32 Re: DBD::Pg 'lo_read' fails on >= 32768 byte large objects