Re: Cygwin PostgreSQL Regression Test Problems (Revisited)

Tom,

On Thu, Mar 29, 2001 at 10:43:49AM -0500, Tom Lane wrote:
> Jason Tishler <Jason(dot)Tishler(at)dothill(dot)com> writes:
> > I get the following backtrace for one of the hung psql processes:
>
> > (gdb) bt
> > #0 0x77f682cb in ?? ()
> > #1 0x77f1cd76 in ?? ()
> > #2 0x6103deee in _size_of_stack_reserve__ ()
> > #3 0x6103d84e in _size_of_stack_reserve__ ()
> > #4 0x67989978 in pqWait (forRead=0, forWrite=1, conn=0xa010258)
> > at fe-misc.c:738
> > #5 0x6798287c in connectDBComplete (conn=0xa010258) at fe-connect.c:1103
> > #6 0x67981fb1 in PQsetdbLogin (pghost=0x0, pgport=0x0, pgoptions=0x0,
> > pgtty=0x0, dbName=0x1a0260e8 "regression", login=0x0, pwd=0x0)
> > at fe-connect.c:524
> > #7 0x40e43f in main (argc=6, argv=0x1a021ad8) at startup.c:178
>
> It would be helpful to see the contents of the conn object ("f 5" then
> "p *conn" should do it).

I did as you suggested above and got the following:

(gdb) f 5
#5 0x6798287c in connectDBComplete (conn=0xa010258) at fe-connect.c:1103
1103 if (pqWait(0, 1, conn))
(gdb) p *conn
$1 = {pghost = 0x0, pghostaddr = 0x0, pgport = 0xa016610 "65432",
pgunixsocket = 0x0, pgtty = 0xa016620 "", pgoptions = 0xa016630 "",
dbName = 0xa017170 "regression", pguser = 0xa017150 "jt",
pgpass = 0xa017160 "", Pfdebug = 0x0,
noticeHook = 0x67984e8c <defaultNoticeProcessor>, noticeArg = 0x0,
status = CONNECTION_STARTED, asyncStatus = PGASYNC_IDLE,
notifyList = 0xa0103e0, sock = 3, laddr = {sa = {sa_family = 0,
sa_data = '\000' <repeats 13 times>}, in = {sin_family = 0,
sin_port = 0, sin_addr = {s_addr = 0},
__pad = "\000\000\000\000\000\000\000"}, un = {sun_family = 0,
sun_path = '\000' <repeats 107 times>}}, raddr = {sa = {sa_family = 1,
sa_data = "/tmp/.s.PGSQL."}, in = {sin_family = 1, sin_port = 29743,
sin_addr = {s_addr = 774860909}, __pad = "s.PGSQL."}, un = {
sun_family = 1,
sun_path = "/tmp/.s.PGSQL.65432", '\000' <repeats 88 times>}},
raddr_len = 21, be_pid = 0, be_key = 0, salt = "\000", lobjfuncs = 0x0,
inBuffer = 0xa0103f0 "", inBufSize = 16384, inStart = 0, inCursor = 0,
inEnd = 0, nonblocking = 0, outBuffer = 0xa0143f8 "", outBufSize = 8192,
outCount = 0, result = 0x0, curTuple = 0x0,
setenv_state = SETENV_STATE_IDLE, next_eo = 0x0, errorMessage = {
data = 0xa016400 "", len = 0, maxlen = 256}, workBuffer = {
data = 0xa016508 "", len = 0, maxlen = 256}, client_encoding = 0}

> If Hiroshi is correct that this is the *first* call to pqWait in
> connectDBComplete, then I think we are looking at a kernel bug (or more
> likely a cygwin bug). psql has opened a TCP connection socket and is
> now waiting for the socket to show as write-ready before it will send
> a connection request. If select() never reports the socket as
> write-ready, you have a hang ... and it's not possible to blame the hang
> on anything else but the kernel. Both ends of the connection are on the
> same machine, so there's no network problem or anything like that.
> There is not anything else that we should need to do at the application
> level before we should be allowed to send data.

Does the details reported above support your hypothesis? If so, can you
assist me in formulating a minimal test case that I can take back to
the Cygwin community?

Thanks,
Jason

--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp. Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason(dot)Tishler(at)dothill(dot)com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com