Open jade2k11598 opened 3 years ago
One more observation. I have noticed that sometimes the callback function gets triggered prematurely, returning a return code of -1 with ec.message()
of " No child processes" (you should see this in the log I attached above), even though the task is not finished. In the callback function A::onReturn
, I actually ignore this (label it as false alarm) but have wondered why this intermittently happens and sometimes it happens without incident (crash or hang). I wouldn't be surprised if this is related to corruption observed above (e.g. not every corruption leads to a crash/hang).
BTW I also ran valgrind on this sample code above and it indicates some corruption (e.g. invalid writes) triggered by sigchld_service.hpp. I've attached the valgrind log. val.txt
I have a code that needs to make a series of
boost::process::async_system
calls that periodically crashes mid-way or gets hung at shutdown.This was built with boost 1.72 on ubuntu 18.04, g++ (Ubuntu 5.5.0-12ubuntu1) 5.5.0 20171010
I was able to simplify this code, where it just triggers the command line
ls -l
. I set up a pool ofboost::asio
threads to which theboost::process::async_system
gets posted to. I don't think that this pool of threads managed byboost::asio
is the problem since I've used it with boost networks for some time now with no problems, but I'll attached that code as well.Below is the simplified code. It serially calls
boost::process::async_system
, that is, as soon as the first async_system returns via callback function, I printout the results ofls -l
and I post anotherboost::process::async_system
using the same command. What you pass to main dictates, how many of this series ofasync_system
calls to make. If you pass it zero, it will only call it once. ThisIOService
is the pool of threads that runs theboost::asio
(see attachment for that); in this case it ran a pool of 4 threads. For logging I just use a thread-safe log (spdlog
) of which I've used often without problems. You can replace it with some other thread-safe logs (didn't want to drag inspdlog
into the files I attached). I put some flushes at various places just to get an idea how far it got before the crash (the flushes should have no impact since it still crashed or hung without it):So when you run this with just one
async_system
call (that is pass the program with a 0 argument), it'll run fine and exit. But anything beyond a singleasync_system
call will either cause a hanging or crash.When I pass the program a 5 (which should trigger 6
async_system
calls), itSegmentation fault
and this was the call stack from the core file it produced:It's a long stack which I also attached. From what I can gather from the log (which is also attached), it appears to be in the process of posting the 4th
async_system
call.It doesn't always crash at the same place. Other times it crashes as it's going down and gives this shorter stack trace:
It either hangs or crashes as long as I have more than one
async_system
call and the stack trace always involvingtcache
.So I had to attach the sample source code as .cpp.txt and .hpp.txt since it would not attach for hpp/cpp files. The log and the backtrace are also attached.
asyncSysTest-2021-03-27-13.17.07.153362.log.txt backtrace.txt async_system_test.cpp.txt IOService.hpp.txt