Re: Bug #1616: assertion failed: comm_generic.c:65: "F->flags.open" onstoreResumeFD.

lör 2006-06-17 klockan 23:21 +0800 skrev Steven Wilton:
> I was guessing that the cause of these problems is in the delay pool code,
> as this is the only feature that uses the deferred code that I don't
> actually use on our proxies, and we've never had a crash with these
> symptoms. Having said that, we don't used squid 2.6 yet either :)

Ok.

Looked at this yesterday and the delay pool code indeed was bad..
registered the fd in the store entry without setting the defer flag, but
it't none of delay pools business.. (just defer the fd, it's
sufficient).

> I'm having problems working out how squid would ever get to the point where
> the server FD would get closed while it is in a deferred state. The only
> time the FD gets deferred is when there is data waiting to be read on the
> socket, and squid decides that it doesn't want to read the data. Once the
> deferred state is set, the fd will not be read until squid removes the
> deferred flag and starts polling the fd again. I didn't think squid would
> close the fd without polling it.

It does if the request is aborted..

client_side.c -> storeAbort -> fwdAbort -> fwdStateFree -> comm_close.

> Is it possible to detect the F->backoff in the fd_close() function, and
> print a warning? Or should an assert be added in fd_close() if the backoff
> flag is set, so we can find out the circumstances under which the server fd
> is being closed with the deferred flag set?.

Good idea.

> One difference I do see in the code is that squid 2.6 does not run the
> read/write handlers on EPOLLHUP or EPOLLERR conditions.

Eh? It does..

read_event = cevents->events & ~EPOLLOUT (any event except EPOLLOUT)
write_event = cevents->events & ~EPOLLIN (any event except EPOLLIN)

> On a slightly different note, I noticed that mem->serverfd uses fd=0 as the
> default (non-backedd off) value. I want to submit a patch to make them
> use -1 instead, as when I first made the patch, I did not think that 0 was a
> valid fd. If you're already working on this part of the code, I thought it
> might be easier for you to make this change and merge it with this patch.
> Please let me know if you;d rather me generate a separate patch for this.

Please do.

If you look at the bug report I have done a preliminary patch which
should clear up the abort/close conditions. But I haven't been able to
reproduce the problem in my current condition.. (can only use the
computer for short intervals, probably should not at all).

Regards
Henrik