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

start validation test panics if process was not set #617

Closed
dongsupark opened this issue Apr 5, 2018 · 4 comments
Closed

start validation test panics if process was not set #617

dongsupark opened this issue Apr 5, 2018 · 4 comments

Comments

@dongsupark
Copy link
Contributor

#578 introduced a new test for StartWithProcUnsetGenError, which is checked by validation/start.go. However, when testing with runc, the test fails because Create() returns exit status 2. It turns out, that's because validateProcessSpec() in runc panics with nil-dereference when its input spec (type of *Process) is nil.

From my understanding, the original idea of the test was probably not to test whether spec.Process is nil or not. It should actually test if process in config.json is valid. So I think we should actually decode a config json file to see if it has a valid process entry.

/cc @liangchenye

@wking
Copy link
Contributor

wking commented Apr 5, 2018

It turns out, that's because validateProcessSpec() in runc panics with nil-dereference when its input spec (type of *Process) is nil.

I have a patch in flight for this with opencontainers/runc#1726.

@wking
Copy link
Contributor

wking commented Apr 5, 2018

From my understanding, the original idea of the test was probably not to test whether spec.Process is nil or not. It should actually test if process in config.json is valid.

From runtime-spec, you should be able to create but not start a container with an unset process (more background on that in opencontainers/runtime-spec#701). The purpose of the StartWithProcUnsetGenError test is to exercise that usecase and ensure that create works (as the spec expects) and the start fails (as the spec requires).

@dongsupark
Copy link
Contributor Author

@wking Thanks.
I hope opencontainers/runc#1726 could be merged.

@wking
Copy link
Contributor

wking commented Apr 6, 2018

I hope opencontainers/runc#1726 could be merged.

Maybe you can find the maintainer-convincing argument that has so far eluded me ;).

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

No branches or pull requests

2 participants