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.

Sign up for GitHub

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

Jump to bottom

Native class doesn't try to load DLL via temp location #26

Closed
gmerkin opened this issue Sep 8, 2016 · 4 comments
Closed

Native class doesn't try to load DLL via temp location #26

gmerkin opened this issue Sep 8, 2016 · 4 comments

Comments

@gmerkin
Copy link
Contributor

gmerkin commented Sep 8, 2016

Native class doesn't try to load DLL via temp location and class loading just fails with java.lang.UnsatisfiedLinkError exception "Native Library %homepath%.jenkins\cache\jars\2C\winp.x64.C29A3A9FA89660FAA034AABD3B4E3E20.dll already loaded in another classloader".
Although there is a code for this purpose, it cannot be reached due to uncought exception.

Particularly it is a root cause of https://issues.jenkins-ci.org/browse/JENKINS-20913
oleg-nenashev added a commit that referenced this issue Oct 13, 2016
@oleg-nenashev
Merge pull request #27 from gmerkin/issue-26
331751d 
Fix issue #26: fall back on loading DLL via temp file
oleg-nenashev added a commit that referenced this issue Nov 6, 2016
@oleg-nenashev
Changelog: Fix JENKINS issue reference for #26
49fa49d
oleg-nenashev added a commit to oleg-nenashev/jenkins that referenced this issue Nov 6, 2016
@oleg-nenashev
Update winp to 1.24. In particular, it addresses issues like [JENKINS…
abfe1de 
…-20913](https://issues.jenkins-ci.org/browse/JENKINS-20913)

### Changes to be picked

### 1.24

Release date: Nov 2, 2016

* [Issue #22](jenkinsci/winp#22) - Winp sometimes kills random processes when using killRecursive. ([PR #23](jenkinsci/winp#23))
* [WINP-10](https://java.net/jira/browse/WINP-10) - Fix for `getCmdLineAndEnvVars()` which fails on x64 versions of Windows. ([PR #20](jenkinsci/winp#20))
* [Issue #24](jenkinsci/winp#24) - Wrong folder when using the `winp.folder.preferred` system property (parent instead of the actual folder). ([PR #25](jenkinsci/winp#25))
* [Issue #26](jenkinsci/winp#26), [JENKINS-20913](https://issues.jenkins-ci.org/browse/JENKINS-20913) - Native class now tries loading DLLs via the temp location. ([PR #27](jenkinsci/winp#27))

### 1.23

Release date: Fev 16, 2015

* Migrate native components to Visual Studio Community 2013. ([PR #14](jenkinsci/winp#14))
* Provide a `winp.unpack.dll.to.parent.dir` property, which disables DLL unpacking to the parent dir. ([PR #14](jenkinsci/winp#12))
@oleg-nenashev oleg-nenashev mentioned this issue Nov 6, 2016
Merged
oleg-nenashev added a commit to jenkinsci/jenkins that referenced this issue Nov 27, 2016
@oleg-nenashev
Update winp to 1.24. In particular, it addresses issues like [JENKINS…
63c2f6c 
…-20913](https://issues.jenkins-ci.org/browse/JENKINS-20913) (#2619)

### Changes to be picked

### 1.24

Release date: Nov 2, 2016

* [Issue #22](jenkinsci/winp#22) - Winp sometimes kills random processes when using killRecursive. ([PR #23](jenkinsci/winp#23))
* [WINP-10](https://java.net/jira/browse/WINP-10) - Fix for `getCmdLineAndEnvVars()` which fails on x64 versions of Windows. ([PR #20](jenkinsci/winp#20))
* [Issue #24](jenkinsci/winp#24) - Wrong folder when using the `winp.folder.preferred` system property (parent instead of the actual folder). ([PR #25](jenkinsci/winp#25))
* [Issue #26](jenkinsci/winp#26), [JENKINS-20913](https://issues.jenkins-ci.org/browse/JENKINS-20913) - Native class now tries loading DLLs via the temp location. ([PR #27](jenkinsci/winp#27))

### 1.23

Release date: Fev 16, 2015

* Migrate native components to Visual Studio Community 2013. ([PR #14](jenkinsci/winp#14))
* Provide a `winp.unpack.dll.to.parent.dir` property, which disables DLL unpacking to the parent dir. ([PR #14](jenkinsci/winp#12))
olivergondza pushed a commit to jenkinsci/jenkins that referenced this issue Dec 6, 2016
@oleg-nenashev @olivergondza
Update winp to 1.24. In particular, it addresses issues like [JENKINS…
e66bfba 
…-20913](https://issues.jenkins-ci.org/browse/JENKINS-20913) (#2619)

### Changes to be picked

### 1.24

Release date: Nov 2, 2016

* [Issue #22](jenkinsci/winp#22) - Winp sometimes kills random processes when using killRecursive. ([PR #23](jenkinsci/winp#23))
* [WINP-10](https://java.net/jira/browse/WINP-10) - Fix for `getCmdLineAndEnvVars()` which fails on x64 versions of Windows. ([PR #20](jenkinsci/winp#20))
* [Issue #24](jenkinsci/winp#24) - Wrong folder when using the `winp.folder.preferred` system property (parent instead of the actual folder). ([PR #25](jenkinsci/winp#25))
* [Issue #26](jenkinsci/winp#26), [JENKINS-20913](https://issues.jenkins-ci.org/browse/JENKINS-20913) - Native class now tries loading DLLs via the temp location. ([PR #27](jenkinsci/winp#27))

### 1.23

Release date: Fev 16, 2015

* Migrate native components to Visual Studio Community 2013. ([PR #14](jenkinsci/winp#14))
* Provide a `winp.unpack.dll.to.parent.dir` property, which disables DLL unpacking to the parent dir. ([PR #14](jenkinsci/winp#12))
(cherry picked from commit 63c2f6c)
@christ66
Copy link
Member

christ66 commented Jan 3, 2017

@oleg-nenashev should this issue be closed since it's fixed?

@oleg-nenashev
Copy link
Member

Yes

@antoxar
Copy link

antoxar commented Jan 13, 2020

Issue reproducible with slave version 3.36.

Jan 12, 2020 8:33:54 PM org.jvnet.winp.Native loadByUrl
WARNING: Failed to load DLL from static location
java.lang.UnsatisfiedLinkError: Native Library C:\jk\remoting\jarCache\44\winp.x64.BFFE30B3B50581290B1866EF8D48C609.dll already loaded in another classloader
at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2456)
at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2684)
at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2617)
at java.base/java.lang.Runtime.load0(Runtime.java:767)
at java.base/java.lang.System.load(System.java:1834)
at org.jvnet.winp.Native.loadDll(Native.java:242)
at org.jvnet.winp.Native.loadByUrl(Native.java:162)
at org.jvnet.winp.Native.load(Native.java:124)
at org.jvnet.winp.Native.(Native.java:93)
at org.jvnet.winp.WinProcess.enableDebugPrivilege(WinProcess.java:245)
at hudson.util.ProcessTree$Windows.(ProcessTree.java:701)
at hudson.util.ProcessTree.get(ProcessTree.java:447)
at hudson.Launcher$RemoteLauncher$KillTask.call(Launcher.java:1103)
at hudson.Launcher$RemoteLauncher$KillTask.call(Launcher.java:1094)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:93)
at java.base/java.lang.Thread.run(Thread.java:834)

@geerligs
Copy link

having same issue with remoting version 3.27:

Apr 22, 2020 8:42:05 AM org.jvnet.winp.Native loadByUrl
WARNING: Failed to load DLL from static location
java.lang.UnsatisfiedLinkError: Native Library C:\jenkins_ci\remoting\jarCache\44\winp.x64.BFFE30B3B50581290B1866EF8D48C609.dll already loaded in another classloader
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1907)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1824)
at java.lang.Runtime.load0(Runtime.java:809)
at java.lang.System.load(System.java:1086)
at org.jvnet.winp.Native.loadDll(Native.java:242)
at org.jvnet.winp.Native.loadByUrl(Native.java:162)
at org.jvnet.winp.Native.load(Native.java:124)
at org.jvnet.winp.Native.(Native.java:93)
at org.jvnet.winp.WinProcess.enableDebugPrivilege(WinProcess.java:245)
at hudson.util.ProcessTree$Windows.(ProcessTree.java:701)
at hudson.util.ProcessTree.get(ProcessTree.java:447)
at hudson.Launcher$RemoteLauncher$KillTask.call(Launcher.java:1103)
at hudson.Launcher$RemoteLauncher$KillTask.call(Launcher.java:1094)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:93)
at java.lang.Thread.run(Thread.java:748)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@antoxar @christ66 @oleg-nenashev @geerligs @gmerkin