3

It seems like boost::process::system is leaking fds:

Let's say I have this simple code to flush iptables config every 3 seconds (just an example):

#include <boost/process.hpp>
#include <thread>


int main(void)
{
  while(true)
  {
    std::this_thread::sleep_for(std::chrono::seconds(3));
    boost::process::system(boost::process::search_path("iptables"), "-F");
  }
  return 0;
}

If I observe the count of open file descriptors by listing /proc/PID/fd |wc -l, I can see that the count increases by one every 3 seconds. Eventually, when it reaches 1024, the program will abort, because the system call will throw an exception with what() stating that there are too many open files!

How can I avoid this fd leakage? I'm using boost 1.69.

EDIT: Replacing boost::process::system with boost::process::child does not seem to help, the child seems to also leak fds, no matter if it gets detached or not.

EDIT 2: Valgrind log with --track-fds=yes: https://termbin.com/d6ud

Jussi Hietanen
  • 181
  • 1
  • 1
  • 12
  • 1
    I execute the code on my machine (fedora25) and I can not see any leak of file descriptors as you mention, are you running the program with root permissions? what os are you using? – camp0 Sep 02 '19 at 07:42
  • @camp0, interesting! I'm running it on Arch Linux, with kernel 5.2.4. I'm running the program with root privileges, yes. Does your boost version match mine? – Jussi Hietanen Sep 02 '19 at 07:45
  • Im running 1.66 and g++ 8.3.1, did you try to execute directly "/usr/bin/iptables"? should be easy to identify where is the problem on your code. – camp0 Sep 02 '19 at 08:00
  • So I'm using 1.69 and 9.1.0, respectively. Using "/usr/bin/iptables" produces the same behaviour; it is still leaking fds. To clarify, the "iptables" command gets executed successfully (the firewall gets flushed). It just still leaks the fd for some reason. – Jussi Hietanen Sep 02 '19 at 08:05
  • 1
    The only thing that comes to my mind is to valgrind the process and see what are that file descriptors to identify the issue. – camp0 Sep 02 '19 at 08:06
  • Very good idea. I've run it in valgrind and linked a paste to the original post. – Jussi Hietanen Sep 02 '19 at 08:15
  • You could also visit `/proc/$(PID)/fd` and check with `ls -la` what fds are open. – schorsch_76 Sep 02 '19 at 11:51
  • @schorsch_76, it seems like it is a bug in the library itself. I will answer and close this one. – Jussi Hietanen Sep 02 '19 at 15:10

1 Answers1

1

The problem seems to be a bug in the specific version (1.69) of boost, and not in the posted code itself. So upgrading boost/patching the bug solves this problem.

The bug report can be found from here: https://github.com/boostorg/process/issues/62

Jussi Hietanen
  • 181
  • 1
  • 1
  • 12