Seg fault in http read event handler caused by rouge event call without context
serg.brester at sebres.de
Mon Nov 18 19:05:39 UTC 2019
18.11.2019 18:11, Maxim Dounin wrote:
> On Mon, Nov 18, 2019 at 05:48:46PM +0100, Sergey Brester wrote:
>> Looks like [efd71d49bde0 ] could be indeed responsible for that: I see at least one state where rev->ready could remain 1 (after rev->available gets 0) e. g. deviation between blocks [efd71d49bde0#l10.8 ] and [efd71d49bde0#l11.8 ] where first did not reset rev->ready and for example if ngx_socket_nread in [efd71d49bde0#l10.38 ] would write 0 into rev->available, so rev->ready remains 1 yet.
> There is no deviation here. The rev->available field holds the
> number of bytes available for reading (or -1 if it's not known),
> while rev->ready indicates if reading is possible. The reading
> can be possible even WHEN REV->AVAILABLE IS ZERO - notably, when
> there is a potential pending EOF.
but I told about the case where rev->ready indicates the READING IS
but REV->AVAILABLE IS LESS AS ZERO.
If you mean this is to noglect, then it is ok, but somehow it looks
backwards incompatible to me.
At least other async-IO procedures (for example KQUEUE ) handle this
Anyway I saw never REV->AVAILABLE LESS AS ZERO, if rev->ready got 1
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nginx-devel