----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/45999/#review128061 -----------------------------------------------------------
3rdparty/libprocess/src/process.cpp (lines 2167 - 2188) <https://reviews.apache.org/r/45999/#comment191447> Is there a reason, we can't just remove the gc process from the list as a preliminary step, and then leave the rest of the logic as is? Followed by the explicit gc terminate/delete? - Kevin Klues On April 11, 2016, 3:48 a.m., Neil Conway wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/45999/ > ----------------------------------------------------------- > > (Updated April 11, 2016, 3:48 a.m.) > > > Review request for mesos and Joris Van Remoortere. > > > Bugs: MESOS-5144 > https://issues.apache.org/jira/browse/MESOS-5144 > > > Repository: mesos > > > Description > ------- > > Without this change, `finalize()` terminates processes in the order > that they happen to be found when iterating over the `processes` > map. That means that if the GarbageCollector process is terminated > while any GC-managed processes are still running, those processes > will not be GC'd (i.e., they will be leaked). > > Fix this by skipping the garbage collector process when iterating > over `processes` in `finalize()`, and then only terminating it after > all other processes have been terminated. > > > Diffs > ----- > > 3rdparty/libprocess/src/process.cpp > 5e9dcfdc52f3a8223bc43af149b8e1f5dbdf5b0a > > Diff: https://reviews.apache.org/r/45999/diff/ > > > Testing > ------- > > make check > > Confirmed reduction of leaked memory via ASAN on Linux/amd64. > > > Thanks, > > Neil Conway > >
