Skip to content
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

Check if stdio pipes are nil for job containers/fix windows.Close usage #1115

Merged
merged 1 commit into from
Aug 23, 2021

Conversation

dcantah
Copy link
Contributor

@dcantah dcantah commented Aug 16, 2021

This change does two things:

  1. Checks if the stdio pipes are nil before closing them via the CloseStdout,
    CloseStderr, CloseStdin methods. This just brings it inline with the other
    cow.Process implementations that check for nilness.
  2. Fix an oversight where windows.Close was being used instead of windows.FreeLibrary
    after loading kernel32.dll

Signed-off-by: Daniel Canter dcanter@microsoft.com

This change does two things:

1. Checks if the stdio pipes are nil before closing them via the CloseStdout,
CloseStderr, CloseStdin methods. This just brings it inline with the other
`cow.Process` implementations that check for nilness.
2. Fix an oversight where windows.Close was being used instead of windows.FreeLibrary
after loading kernel32.dll

Signed-off-by: Daniel Canter <dcanter@microsoft.com>
@dcantah dcantah requested a review from a team as a code owner August 16, 2021 12:27
@dcantah dcantah changed the title Misc. job containers cleanup Check if stdio pipes are nil for job containers/fix windows.Close usage Aug 17, 2021
Copy link
Contributor

@anmaxvl anmaxvl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. were we hitting nil deref somehow?

@dcantah
Copy link
Contributor Author

dcantah commented Aug 23, 2021

@anmaxvl Nope, but was scared of one happening somehow (and the other cow.Container's check also so 🤷‍♂️)

@@ -217,7 +235,9 @@ func signalProcess(pid uint32, signal int) error {
if err != nil {
return errors.Wrap(err, "failed to open process")
}
defer windows.Close(hProc)
defer func() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These could just be left as the original defer windows.Close(hproc) with no functionality change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think our linter was whining about it as we weren't handling the error, but begs the question of how it didn't whine the first time..

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me look what we can get away with

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

internal\jobcontainers\process.go:252:27: Error return value of windows.FreeLibrary is not checked (errcheck)
defer windows.FreeLibrary(k32)

Seems to only care about the freelibrary for some odd reason

Copy link
Contributor

@msscotb msscotb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

Copy link
Contributor

@msscotb msscotb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants