You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm reducing the lua interpreter using cvise. The interestingness oracle compiles and runs the interpreter.
I noticed that cvise would frequently get stuck, and an inspection of the process table shows that many lua processes were running well beyond the allocated timeout. It appears that you need to be more forceful than SIGTERM to reliably kill lua. SIGKILL seems to be sufficient (but see the caveat below).
So I wonder if it would be nice to add the ability to specify the signal that is sent to the process upon timeout (or maybe you could even allow an arbitrary shell command, in case you want to do something that isn't sending a signal?).
For now I've hacked the cvise source code to have it send a sigkill:
diff --git a/cvise/utils/testing.py b/cvise/utils/testing.py
index 2300c3c..15da7fa 100644
--- a/cvise/utils/testing.py+++ b/cvise/utils/testing.py@@ -362,7 +362,7 @@ class TestManager:
children.append(process)
for child in children:
try:
- child.terminate()+ child.kill()
except psutil.NoSuchProcess:
pass
except psutil.NoSuchProcess:
A colleague mentioned that he had this same issue and wrapped the oracle in timeout(1) in order to SIGKILL the interpreter.
But here's a hitch, with the above patch applied, cvise gets stuck much, much less frequently, but on occasion still does:
For example, above the timeout is 60 seconds, yet a lua process has been running for over an hour. When this happens, so far I've just been manually kill -9ing the PID to allow cvise to continue. The processes have realiably died when I've manually killed them in this way. SIGKILL is unmaskable, so that's what I'd expect.
But I wonder how this can happen. Could there be a bug in cvise's killing logic?
I'm using cvise master branch (commit 16a34b2) with the above patch on Debian/amd64.
The text was updated successfully, but these errors were encountered:
(one can potentially specify a signal for the timeout command). Can you please give it a try if it's a more reliable approach?
Sure, I would be happy to accept such a PR that will add the possibility to specify the signal, but I'm a bit sad one can still face the unpleasant situation where the process is blocking C-Vise :/
Hi,
I'm reducing the lua interpreter using cvise. The interestingness oracle compiles and runs the interpreter.
I noticed that cvise would frequently get stuck, and an inspection of the process table shows that many lua processes were running well beyond the allocated timeout. It appears that you need to be more forceful than SIGTERM to reliably kill lua. SIGKILL seems to be sufficient (but see the caveat below).
So I wonder if it would be nice to add the ability to specify the signal that is sent to the process upon timeout (or maybe you could even allow an arbitrary shell command, in case you want to do something that isn't sending a signal?).
For now I've hacked the cvise source code to have it send a sigkill:
A colleague mentioned that he had this same issue and wrapped the oracle in
timeout(1)
in order to SIGKILL the interpreter.But here's a hitch, with the above patch applied, cvise gets stuck much, much less frequently, but on occasion still does:
For example, above the timeout is 60 seconds, yet a lua process has been running for over an hour. When this happens, so far I've just been manually
kill -9
ing the PID to allow cvise to continue. The processes have realiably died when I've manually killed them in this way. SIGKILL is unmaskable, so that's what I'd expect.But I wonder how this can happen. Could there be a bug in cvise's killing logic?
I'm using cvise master branch (commit 16a34b2) with the above patch on Debian/amd64.
The text was updated successfully, but these errors were encountered: