mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Mahler <bmah...@apache.org>
Subject Re: Review Request 50163: Fixed a memory lifetime issue in LibeventSSLSocketImp::send.
Date Tue, 19 Jul 2016 01:19:04 GMT


> On July 18, 2016, 10:01 p.m., Joris Van Remoortere wrote:
> > 3rdparty/libprocess/src/libevent_ssl_socket.cpp, line 715
> > <https://reviews.apache.org/r/50163/diff/1/?file=1446203#file1446203line715>
> >
> >     Let's pull out the side-effect and feed it to the check.

In retrospect it seems ok to in some cases to have side-effects within CHECKs, mostly in the
case of CHECK_NOTNULL:

```
  evbuffer* buffer = CHECK_NOTNULL(evbuffer_new());
```

Because this reads well and will show the contents of the check ("evbuffer_new()") in the
error message. However, pulling them out for add and write_buffer does seem more readable
to me:

```
  CHECK_EQ(0, evbuffer_add(buffer, data, size));
  CHECK_EQ(0, bufferevent_write_buffer(self->bev, buffer));

// vs

  int result = evbuffer_add(buffer, data, size);
  CHECK_EQ(0, result);

  int result = bufferevent_write_buffer(self->bev, buffer);
  CHECK_EQ(0, result);
```

So I'll pull them out for these two, but I'll use our CHECK_NOTNULL pattern. Sound good?


> On July 18, 2016, 10:01 p.m., Joris Van Remoortere wrote:
> > 3rdparty/libprocess/src/libevent_ssl_socket.cpp, lines 714-715
> > <https://reviews.apache.org/r/50163/diff/1/?file=1446203#file1446203line714>
> >
> >     I think it's ok to do a `CHECK` on the result of `evbuffer_add` if you test
`buffer` for `nullptr` first.
> >     We should return a failure if the allocation failed though right?

For CHECK vs Failure, good question! I read their code and saw that the only way that evbuffer_add
can fail is in the case of us making a programming error, or memory allocation failing. Also
their documentation only makes a vague mention of -1 on error, no error code mechanism is
provided, and no error cases are documented. :(

So it seems safe to CHECK that this doesn't fail since it's not an expected run-time error.


> On July 18, 2016, 10:01 p.m., Joris Van Remoortere wrote:
> > 3rdparty/libprocess/src/libevent_ssl_socket.cpp, lines 735-736
> > <https://reviews.apache.org/r/50163/diff/1/?file=1446203#file1446203line735>
> >
> >     Why `CHECK` vs `Failure`?

Ditto here w.r.t. not an expected run-time error: from reading their code it seems this can
only fail via a programmer error or a memory allocation failure. If there were any other reasons
I would have used a Failure indeed! Wish they would document and return error codes.. :(


- Benjamin


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


On July 18, 2016, 9:40 p.m., Benjamin Mahler wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/50163/
> -----------------------------------------------------------
> 
> (Updated July 18, 2016, 9:40 p.m.)
> 
> 
> Review request for mesos, Joris Van Remoortere and Joseph Wu.
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> This function accidentally assumed that 'data' will live beyond the
> scope of the call, by using 'data' within an asynchronous context.
> 
> This copies the data into an 'evbuffer' which will then get moved
> into the output buffer in the event loop. Note that this does not
> introduce an additional copy: we still have a single copy to get
> 'data' into the bufferevent output buffer.
> 
> AFAICT, this bug is currently not triggered from any of the calling
> code because each call-site deletes the 'data' after the Future
> completes (it appears that the 'send_callback' will be executed
> *after* the call to bufferevent_write and after the output buffer
> is flushed).
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/src/libevent_ssl_socket.cpp 2e7f33241b5291593cac4ea4c8f0351c19f7f0c2

> 
> Diff: https://reviews.apache.org/r/50163/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Benjamin Mahler
> 
>


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