https://svn.boost.org/trac10/ticket/13139 <p> Create a child process. Let it die abnormally (for example, calling <code>kill(getpid(), SIGABRT)</code> in the child). In the parent, call <code>child.join()</code>. </p> <p> It appears that the <code>::waitpid</code> loop in <code>boost::process::detail::posix::wait</code> at github.com/boostorg/process/blob/boost-1.64.0/include/boost/process/detail/posix/wait_for_exit.hpp#L26-L31 only checks that the child ended because of a call to <code>::exit()</code> and does not check for exiting via signal (<code>WIFSIGNALED()</code>). </p> <p> Because <code>WIFSIGNALED()</code> is true, <code>WIFEXITED()</code> is false; and because it's false, the loop will continue and call <code>::waitpid()</code> again... this time with a child PID to a process which has already been reaped. <code>waitpid()</code> will report an error (indicating that there's no such child prcess), and the error will be thrown. </p> <p> The child's exact reason for exiting is lost, which is why I believe this should be marked a "Showstopper" severity; a workaround would be to avoid calling <code>boost::process::wait()</code> in any fashion and to instead use a custom waitpid loop using the <code>child.native_handle()</code>. </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/13139 Trac 1.4.3 keithb@… Thu, 27 Jul 2017 19:47:25 GMT https://svn.boost.org/trac10/ticket/13139 https://svn.boost.org/trac10/ticket/13139 <ul> <li><strong>attachment</strong> → <span class="trac-field-new">killer.c</span> </li> </ul> <p> killer.c: a simple C app that sends a specified signal number to itself </p> Ticket keithb@… Thu, 27 Jul 2017 19:48:11 GMT https://svn.boost.org/trac10/ticket/13139 https://svn.boost.org/trac10/ticket/13139 <ul> <li><strong>attachment</strong> → <span class="trac-field-new">killer-test.cpp</span> </li> </ul> <p> killer-test.cpp: small application that uses boost::process library to exercise the killer app which would be produced by killer.c </p> Ticket