----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/66863/#review202139 -----------------------------------------------------------
Fix it, then Ship it! 3rdparty/libprocess/src/process.cpp Lines 1762-1772 (patched) <https://reviews.apache.org/r/66863/#comment283771> Alternatively, we could do ``` _send(encoder, socket).then([=] { // Loop until this socket has no more encoded messages to send. return process::loop( None(), [=] { return socket_manager->next(socket); } [=](Encoder* encoder) -> Future<ControlFlow<Nothing>> { if (encoder == nullptr) { return Break(); } return _send(encoder, socket) .then([]() -> ControlFlow<Nothing> { return Continue(); }); }) }); ``` And clean up `encoder` in `_send`: ``` return process::loop( None(), [=]() { ... return send .then(...) .recover([=](const Future<Nothing>& f) { socket_manager->close(socket); delete encoder; return f; // Break the loop by propagating the "failure". }); }, [=](Nothing) -> ControlFlow<Nothing> { if (encoder->remaining() == 0) { delete encoder; return Break(); } return Continue(); }); ``` Please feel free to drop this if you prefer the current version. 3rdparty/libprocess/src/process.cpp Lines 1779 (patched) <https://reviews.apache.org/r/66863/#comment283773> How about `const Future<Nothing>& f`? 3rdparty/libprocess/src/process.cpp Lines 1823 (patched) <https://reviews.apache.org/r/66863/#comment283774> Seems we have code with both `(Nothing)` and `(const Nothing&)`, so I'm not raising an issue here. - Chun-Hung Hsiao On April 29, 2018, 1:40 a.m., Benjamin Mahler wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/66863/ > ----------------------------------------------------------- > > (Updated April 29, 2018, 1:40 a.m.) > > > Review request for mesos, Benjamin Hindman, Benno Evers, and Chun-Hung Hsiao. > > > Bugs: MESOS-8594 > https://issues.apache.org/jira/browse/MESOS-8594 > > > Repository: mesos > > > Description > ------- > > Currently, the socket send path is implemented using an asynchronous > loop with callbacks. Without using `process::loop`, this pattern is > prone to a stack overflow in the case that all asynchronous calls > complete synchronously. This is possible with sockets if the socket > is always ready for writing. Users have reported the crash in both > MESOS-8594 and MESOS-8834, so the stack overflow is encountered in > practice. > > This patch updates the send path to leverage `process::loop`, which > is supposed to prevent stack overflows in asynchronous loops. However, > it is still possible for `process::loop` to stack overflow due to > MESOS-8852. In practice, I expect that even without MESOS-8852 fixed, > users won't see any stack overflows in the send path. > > > Diffs > ----- > > 3rdparty/libprocess/src/process.cpp > 21931db5edd7ecf0f4620dba42a5521f48cd47a3 > > > Diff: https://reviews.apache.org/r/66863/diff/1/ > > > Testing > ------- > > make check > > > Thanks, > > Benjamin Mahler > >
