-
Notifications
You must be signed in to change notification settings - Fork 25
rescue less #55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rescue less #55
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,45 @@ | ||
require "open3" | ||
require "timeout" | ||
|
||
module CC | ||
module Engine | ||
module Analyzers | ||
class CommandLineRunner | ||
DEFAULT_TIMEOUT = 300 | ||
|
||
def initialize(command, timeout = DEFAULT_TIMEOUT) | ||
@command = command | ||
@timeout = timeout | ||
end | ||
|
||
def run(input) | ||
Timeout.timeout(timeout) do | ||
Open3.popen3 command, "r+" do |stdin, stdout, stderr, wait_thr| | ||
stdin.puts input | ||
stdin.close | ||
|
||
exit_code = wait_thr.value | ||
|
||
output = stdout.gets | ||
stdout.close | ||
|
||
err_output = stderr.gets | ||
stderr.close | ||
|
||
if 0 == exit_code | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I noticed that there was a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nope. Different invocation. This is already an int. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 👍 |
||
yield output | ||
else | ||
raise ::CC::Engine::Analyzers::ParserError, "Python parser exited with code #{exit_code}:\n#{err_output}" | ||
end | ||
end | ||
end | ||
end | ||
|
||
private | ||
|
||
attr_reader :command, :timeout | ||
end | ||
end | ||
end | ||
end | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,7 @@ | ||
module CC | ||
module Engine | ||
module Analyzers | ||
ParserError = Class.new(StandardError) | ||
end | ||
end | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Opinion question for the team: should we also catch
Timeout::Error
? Flay does internally (not in a code path we're using, FWIW). I think the thinking behind it was that if the parser took too long on a file, it's probably a parser bug (or maybe an absurdly large file). We were implicitly catching it before.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd try to match the behavior of Flay run on the command line then. If the Flay catches the timeout error, logs a skip, and continues on, then I think that we should do the same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dblandin 's reasoning sounds good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree as well. It has been added now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I'm going to back this out: I remembered why I was hesitant about this in the first place. This series of changes was prompted by concerns of non-deterministic results from this engine (due to memory settings, but really a variety of system issues could come into play).
These timeouts are, by their nature, slightly non-deterministic. a file complex & big enough to be borderline might timeout some times & not others. Memory pressure on the system could cause execution time to vary between one run & another. Etc.
So instead I think I'm going to consider the timeout errors fatal & up the timeout limit to something absurd like 5 minutes. That should ensure it only gets triggered in pathological cases (like a parser bug leading to an infinite loop or something).
@jpignata this is relevant to your interests, so your thoughts are welcome.