Re: [Boost-users] Memory deallocation concerning boost::bind, boost::asio and shared_ptr

Subject: Re: [Boost-users] Memory deallocation concerning boost::bind, boost::asio and shared_ptr
From: Lee Clagett (forum_at_[hidden])
Date: 2016-04-29 00:19:24

On Thu, 28 Apr 2016 12:14:00 -0700 (PDT)
Norman <kradepon_at_[hidden]> wrote:
> Alright, i made an example, that shows my problem:
> 
> http://melpon.org/wandbox/permlink/S56tYueJySIHdsWO

This does not show any problem, although I am uncertain on the intent
of the `async_accept` calls. The only non-completed handler in the
"during" stage should be the async_wait, however there is no guaranteed
sequencing between the acceptor handlers and the async_wait handler.
The counter indicates all of the other callbacks have completed in my
executions of the code.

The during and after printing only indicate the RSS is the same at
those two execution points. This does not necessarily indicate a
problem. In fact, the following `stop` call could result in a RSS
increase (additional code page mapping), and then the RSS could
decrease to the prior level after the `async_wait` and `run` complete
and free any used memory. I simply do not see any information learned
from this example.

> Vinnie_win aka. Vinnie falco told me, that I might be looking at the
> wrong indicator for my memory use. But I thought the Resident Set
> Size is the value to look for, since I want to know how much memory
> my program is currently allocating.
> 
> Any help would still be really appriciated :-)
> 

The RSS value indicates the number of virtual pages that have a
physical page mapping for the process. There is no guaranteed
correlation between the amount of memory requested via new/delete OR
the amount of memory being managed by the C++ runtime. "Allocated"
memory being managed by the C++ runtime can be swapped to disk which
lowers the RSS but not the amount of memory being managed by the
runtime. New code segments can be executed which requires additional
pages of the mmap'ed executable or shared library to be copied to
physical memory which will increase the RSS but not the amount of
memory being managed by the C++ runtime. A large allocation into the
C++ runtime can be fulfilled with a single anonymous mmap which delays
any RSS increase until the page(s) have been "touched". As an example
(stealing your getUsedMemory function):

    #include <fstream>
    #include <iostream>
    #include <memory>
    #include <string>

    #include <boost/algorithm/string.hpp>

    std::string getUsedMemory() {
      try {
        std::ifstream inFile("/proc/self/status");

        if (!inFile.good()) {
          std::cout << "Cannot open status file." << std::endl;
        }

        std::string line;
        while (std::getline(inFile, line)) {
          if (boost::starts_with(line, "VmRSS:")) {
            inFile.close();
            return std::string(&line[7], line.size() - 7);
          }
        }
        inFile.close();
      } catch (std::exception& e) {
        std::cout << " Exception: " << e.what() << std::endl;
      }
      return "Unknown";
    }

    int main() {
        std::unique_ptr<char[]> bytes(new char[50*1024*1024]); // 50 MiB
        std::cout << "Used memory: " << getUsedMemory() << std::endl;
        return 0;
    }

That is unlikely to print 50+ MiB of "used memory". Wandbox (Gcc
5.3) prints:

    Used memory:     5968 kB

And my local box prints even less. It is probably easier to use the
tools I mentioned earlier or something like massif if you are trying to
track general process memory usage or leaks.

Lee