mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chun-Hung Hsiao <chhs...@apache.org>
Subject Re: Review Request 66863: Reduced likelihood of a stack overflow in libprocess socket send path.
Date Mon, 30 Apr 2018 21:11:50 GMT

-----------------------------------------------------------
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
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message