-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41026/#review109246
-----------------------------------------------------------


Would it be plausible to write a repro/test (in the libprocess level) for this?

Presumably, we should be able to write a process that does a "long running 
streaming download" (which causes the bug, according to your diagnosis).

- Joseph Wu


On Dec. 7, 2015, 5:22 p.m., Jojy Varghese wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/41026/
> -----------------------------------------------------------
> 
> (Updated Dec. 7, 2015, 5:22 p.m.)
> 
> 
> Review request for mesos and Joris Van Remoortere.
> 
> 
> Bugs: MESOS-4069
>     https://issues.apache.org/jira/browse/MESOS-4069
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> recv_callback could be called from libevents receive callback and Socket::recv
> for the same buffer event and different requests. There is a check for buffer
> length at Socket::recv but not at libevent's receive callback. This could lead
> to the incoming request for Socket::recv being swapped out even though the
> buffer length is zero. This change adds a check for buffer length before
> swapping out the receive request object.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/src/libevent_ssl_socket.cpp 
> 55b91dd47bb5bd5e97147d0af91c7899fd42702c 
> 
> Diff: https://reviews.apache.org/r/41026/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Jojy Varghese
> 
>

Reply via email to