Re: [PATCH] 3.2.0.6 assertion failed: comm.cc:216: "fd_table[fd].halfClosedReader != NULL"

On 04/05/2011 05:38 AM, Amos Jeffries wrote:
> Debugging on IRC revealed this to be caused by some as yet unidentified
> bug in client-side CONNECT handling.
>
> The client-side leaves a read handler registered when tunnel is handed
> the client FD to start pushing bytes. The attached patch works around
> that by making tunnel detect the existing handler and cancel it.
>
> This is a quite nasty workaround. Proposed only as a workaround patch
> until a real fix can be figured out and tested.

Client side has:

  - do_next_read (several incarnations): usually used to trigger
comm_read in the caller;

  - mayUseConnection: is sometimes used to avoid triggering comm_read
even though its intent was to reserve the connection for the current
request (i.e., the intent was to avoid switching to the next request,
rather than avoiding reading from the socket);

  - conn->flags.readMoreRequests: Kind of like do_next_read but more
persistent as it is stored in the context flags rather than a local
variable. A true do_next_read value can cause the readMoreRequests flag
to be set, but setting do_next_read to false may not clear the flag.

I will try to polish the above a little instead of just contributing to
the current insanity, but it may not be possible. Meanwhile, the change
below avoids the CONNECT assertion for the one case I reproduced:

> if (context->mayUseConnection()) {
> debugs(33, 3, HERE << "Not reading, as this request may need the connection");
> - return false;
> + do_next_read = false;
> + break;
> }

HTH,

Alex.
Received on Wed Apr 06 2011 - 17:48:22 MDT