> On Dec. 8, 2015, 1:43 a.m., Joseph Wu wrote: > > 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).
The steps described in the bug is a good way to test. I was able to repro the issue 1/10 times. Since this is a race condition, will be hard to write test. - Jojy ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/41026/#review109246 ----------------------------------------------------------- On Dec. 8, 2015, 1:22 a.m., Jojy Varghese wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/41026/ > ----------------------------------------------------------- > > (Updated Dec. 8, 2015, 1:22 a.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 > >
