Re: bug #94 news

On Tue, Oct 01, 2002, Henrik Nordström wrote:
> Which tells us a quite interesting story of what happened
>
> 1. The connection to the server failed, causing fwdStart to restart via a
> dummy event (see fwdServerClosed). This is known by the fact that this is
> the only case where fwdConnectStart is called via eventRun().
>
> 2. When the server connection was restarted in fwdConnectStart we picked
> up a persistent connection. This can be told by having a straight
> stacktrace fwdServerStart() -> fwdConnectDone(). In case of a new
> connection it always goes via the comm_poll main loop.
>
> 3. And for some reason, the filedescriptor of this persistent connection
> did not make out as a correct filedescriptor when http.c tried to send a
> request onto it.
>
> So a good measure would be to try to trap this error in fwdConnectStart().
> If pconnPop returns a filedescriptor that does not make out as correct
> then yell loudly and forget about it.. then try to identity why there is
> "invalid" filedescriptors in the persistent connection heap/stack.
>

You're talking about:

(gdb) frame 3
#3 0x0003b98c in httpSendRequest (httpState=0x787010) at http.c:952
952 assert(-1 == cfd || FD_SOCKET == fd_table[cfd].type);

, right?

(gdb) bt
#0 0x9001bc0c in kill ()
#1 0x9005d5cc in abort ()
#2 0x00025574 in xassert (msg=0x220a "", file=0x0, line=0) at debug.c:278
#3 0x0003b98c in httpSendRequest (httpState=0x787010) at http.c:952
#4 0x0002c810 in fwdConnectDone (server_fd=12, status=640276, data=0x76cdf8) at forward.c:237
#5 0x00024544 in comm_select (msec=1124768) at comm_select.c:540
#6 0x00049f68 in main (argc=736, argv=0x96824) at main.c:715
#7 0x00002604 in _start (argc=2, argv=0xbffffd94, envp=0xbffffda0) at /SourceCache/Csu/Csu-45/crt.c:267
#8 0x00002484 in start ()
(gdb)

and, yes, cfd has been closed.

So, I added in some debugging code which trapped the comm_close() to an FD and whittled it away.

(gdb) print cfd
$17 = 11
(gdb) print fdd_table[cfd]
$18 = {
  close_file = 0x7f234 "client_side.c",
  close_line = 1317
}
(gdb)

.. which, in clientReadRequest, gives:

    } else if (connReadWasError(conn, size)) {
--> comm_close(fd);
        return;
    }

So, it _sounds_ like a possible problem with BOTH persistent client/server connections, perhaps?
Can we get around needing the client fd hidden away in the mem_obj?

Adrian
Received on Thu Oct 03 2002 - 19:11:10 MDT