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

org.jvnet.winp.WinpException: Failed to read environment variable - [JENKINS-30782] #29

Closed
oleg-nenashev opened this issue Mar 3, 2017 · 1 comment
Assignees
Labels

Comments

@oleg-nenashev
Copy link
Member

According to the code, the getCmdLineAndEnvVars() command is unreliable on newer modern OS versions.

The last ReadProcessMemory command may fail:

	// Checking the read size is more likely to result in success than checking the BOOL that is
	// returned by ReadProcessMemory, on newer versions of Windows. That said, neither approach
	// is particularly reliable past Vista. This approach differs from checking the BOOL in that
	// it will succeed for partial reads that read _some_ data, where the other approach fails.

There are many usages of the command in WinP itself and in the dependent codebase like Jenkins ( JENKINS-30782). Example of the log in Jenkins:

The error that I get is ERROR: Build step failed with exception
org.jvnet.winp.WinpException: Failed to read environment variable table error=299 at .\envvar-cmdline.cpp:201
at org.jvnet.winp.Native.getCmdLineAndEnvVars(Native Method)
at org.jvnet.winp.WinProcess.parseCmdLineAndEnvVars(WinProcess.java:126)
at org.jvnet.winp.WinProcess.getCommandLine(WinProcess.java:102)
at org.jvnet.winp.WinProcess.killRecursively(WinProcess.java:66)
at hudson.util.ProcessTree$Windows$1.killRecursively(ProcessTree.java:425)
at hudson.util.ProcessTree.killAll(ProcessTree.java:141)
at hudson.Proc$LocalProc.destroy(Proc.java:379)
at hudson.Proc$LocalProc.join(Proc.java:352)
at hudson.Launcher$ProcStarter.join(Launcher.java:389)
at hudson.tasks.Ant.perform(Ant.java:217)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:779)
at hudson.model.Build$BuildExecution.build(Build.java:205)
at hudson.model.Build$BuildExecution.doRun(Build.java:162)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:537)
at hudson.model.Run.execute(Run.java:1741)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:408

Proposals:

  • Fix the failing ReadProcessMemory operation if possible
  • Reduce the scope of the EnvVars usage, provide API for retrieving the CMD Line only
  • It won't help Jenkins, which terminates processes by using EnvVars filters (e.g. by BUILD_NUMBER env. var)
@oleg-nenashev oleg-nenashev self-assigned this Mar 24, 2017
oleg-nenashev added a commit to oleg-nenashev/winp that referenced this issue Mar 24, 2017
…t the command line

It does not resolve the issue, but it reduces its scope to API users, which actually require Environment Variables.
Unfortunately JENKINS-30782 is of such kind, because Jenkins process termination logic for builds relies on the environment variables.
oleg-nenashev added a commit that referenced this issue Apr 12, 2017
Issue #29 - Do not retrieve Environment variables just to get the command line
oleg-nenashev added a commit to oleg-nenashev/winp that referenced this issue Apr 19, 2017
oleg-nenashev added a commit to oleg-nenashev/winp that referenced this issue Apr 19, 2017
oleg-nenashev added a commit to oleg-nenashev/winp that referenced this issue Apr 19, 2017
oleg-nenashev added a commit to oleg-nenashev/winp that referenced this issue Apr 25, 2017
oleg-nenashev added a commit to oleg-nenashev/winp that referenced this issue Apr 25, 2017
oleg-nenashev added a commit to oleg-nenashev/winp that referenced this issue Apr 25, 2017
oleg-nenashev added a commit that referenced this issue May 5, 2017
[Issue #29] - Improve diagnostics of Process reading in the native code
@oleg-nenashev
Copy link
Member Author

Closing the issue since it is not possible to get such stacktrace anymore since 1.25. Instead of that one will get more diagnostics

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

No branches or pull requests

1 participant