Seg fault in http read event handler caused by rouge event call without context

[Sergey Brester]

18.11.2019 18:11, Maxim Dounin wrote: 

> Hello!
> 
> On Mon, Nov 18, 2019 at 05:48:46PM +0100, Sergey Brester wrote:
> 
>> Looks like [efd71d49bde0 [2]] 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 [3]] and [efd71d49bde0#l11.8 [4]] where first did not reset rev->ready and for example if ngx_socket_nread in [efd71d49bde0#l10.38 [5]] 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.

Sure, 
but I told about the case where rev->ready indicates the READING IS
POSSIBLE, 
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 [1]) handle this
differently. 

Anyway I saw never REV->AVAILABLE LESS AS ZERO, if rev->ready got 1
until now.

Regards,
Sergey. 

Links:
------
[1]
https://github.com/nginx/nginx/commit/fac4c7bdf53ee7d8fec6568f1e9fecefcde6feba#diff-0b707fd972a54f561081982c62457febR155-R158
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20191118/b97a3cb4/attachment.htm>