From 21d9de83f7665c698e835c528f50ba32bc15d05a Mon Sep 17 00:00:00 2001 From: Kevin Day Date: Mon, 18 Jul 2022 22:35:29 -0500 Subject: [PATCH] Bugfix: Guarantee that the child processes are terminated. The terminate signal is not being received for unknown reasons. The signals are unblocked for the child process. And yet, it continues to block. The final part of the terminate due to signal is to forcibly terminate (sending the kill signal). This is now happening for child processes. Sending the kill signal allieviates the problem where the controller program will not terminate. This fix causes the reduces the severity of the problem such that the terminate should still terminate. However, this fix does not solve the problem with the terminate signal not being received by a child process that is not blocking the signal as far as I can tell. --- level_3/controller/c/thread/private-thread_process.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/level_3/controller/c/thread/private-thread_process.c b/level_3/controller/c/thread/private-thread_process.c index a172386..57e046f 100644 --- a/level_3/controller/c/thread/private-thread_process.c +++ b/level_3/controller/c/thread/private-thread_process.c @@ -233,7 +233,16 @@ extern "C" { } for (j = 0; j < process->childs.size; ++j) { - process->childs.array[j] = 0; + + if (process->childs.array[j]) { + + // A hackish way to determine if the child process exists, and if it does then forcibly terminate it. + if (getpgid(process->childs.array[j]) >= 0) { + f_signal_send(F_signal_kill, process->childs.array[j]); + } + + process->childs.array[j] = 0; + } } // for process->childs.used = 0; -- 1.8.3.1