Re: Cygwin PostgreSQL Regression Test Problems (Revisited)

Tom,

On Thu, Mar 29, 2001 at 10:43:49AM -0500, Tom Lane wrote:
> Jason Tishler <Jason.Tishler@dothill.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.Tishler@dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com