----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/49404/#review140079 -----------------------------------------------------------
Ship it! Looks good, thanks! Can you also sweep up the remaining Socket pointers that were not as related to the race you found? 3rdparty/libprocess/src/process.cpp (line 1838) <https://reviews.apache.org/r/49404/#comment205390> For example, no need for a pointer here. 3rdparty/libprocess/src/process.cpp (line 1847) <https://reviews.apache.org/r/49404/#comment205389> Or here, etc. - Benjamin Mahler On June 29, 2016, 11:56 p.m., Joseph Wu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/49404/ > ----------------------------------------------------------- > > (Updated June 29, 2016, 11:56 p.m.) > > > Review request for mesos, Benjamin Mahler and Artem Harutyunyan. > > > Bugs: MESOS-5748 > https://issues.apache.org/jira/browse/MESOS-5748 > > > Repository: mesos > > > Description > ------- > > `Sockets` is already a reference-counted `shared_ptr` under the covers. > By passing around `Sockets` by value, we avoid potentially deleting > a reference while the same reference is in use by another function. > > This fixes a rare race (segfault) between `link`/`send` and > `ignore_recv_data`. If the peer of the socket exits between > establishing a connection and libprocess queuing a `MessageEncoder`, > `ignore_recv_data` may delete the `Socket` underneath the `link`/`send`. > > > Diffs > ----- > > 3rdparty/libprocess/src/process.cpp > 9bae71246e751e491be5a989eea8aca29c9aa751 > > Diff: https://reviews.apache.org/r/49404/diff/ > > > Testing > ------- > > make check (OSX) > > 3rdparty/libprocess/libprocess-tests > --gtest_filter="ProcessRemoteLinkTest.RemoteLink" --gtest_break_on_failure > --gtest_repeat=10000 > > > Thanks, > > Joseph Wu > >
