Hi Pete,
I see you've already tried the Dependency Walker.
1. Could you please clarify the following: if you compile two lists of
dependencies, one for JavaAccessBridge.dll and another for
JAWTAccessBridge.DLL, and compare them, are there any differences?
2. If you change the order of loading the libraries, will it fail right
away w/o even loading the JavaAccessBridge.dll ?
3. If the above doesn't help, please post the full list of dependencies
for JAWTAccessBridge.DLL as reported by the Dependency Walker.
--
best regards,
Anthony
On 12/16/2013 08:02 PM, Pete Brunet wrote:
I'm writing a regression test and it is failing trying to load
bin\JAWTAccessBridge.DLL. It was successful in loading
bin\JavaAccessBridge.dll just prior to the failure. These two DLLs are
in jre\bin. Here's the failure:
java.lang.UnsatisfiedLinkError:
C:\\Users\\Pete\\JDK8\\JDK-8029691\\jdk8\\build\\windows-x86-normal-server-release\\images\\j2sdk-image\\jre\\bin\\JAWTAccessBridge.dll:
Can't find dependent libraries
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1929)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1119)
at JABDLL$4.run(JABDLL.java:116)
at java.security.AccessController.doPrivileged(Native Method)
at JABDLL.foundLegacyDLLs(JABDLL.java:113)
at JABDLL.main(JABDLL.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
at java.lang.Thread.run(Thread.java:744)
Here's the pertinent code:
private static boolean foundLegacyDLLs() {
java.security.AccessController.doPrivileged(
new java.security.PrivilegedAction() {
public Object run() {
System.loadLibrary("JavaAccessBridge");
return null;
}
}, null, new
RuntimePermission("loadLibrary.JavaAccessBridge")
);
java.security.AccessController.doPrivileged(
new java.security.PrivilegedAction() {
public Object run() {
System.loadLibrary("JAWTAccessBridge"); // line
116, fails here
return null;
}
}, null, new
RuntimePermission("loadLibrary.JAWTAccessBridge")
);
return true;
}
Here's the jtreg run:
$ /cygdrive/c/Users/Pete/JDK8/jtreg/win32/bin/jtreg
-testjdk:/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/images/j2sdk-image
-verbose:summary closed/com/sun/java/accessibility/JABDLL.java
C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\TEST.groups: group
needs_jre: file not found: java/text/Bidi/Bug6665028.java // assume
this can be ignored
FAILED: closed/com/sun/java/accessibility/JABDLL.java
Test results: failed: 1
Report written to
C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTreport\html\report.html
Results written to C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTwork
Error: Some tests failed or other problems occurred.
Here's the prolog to the test case:
/*
* @test
* @summary ...
* @run main JABDLL
*/
The built image runs fine in normal use, i.e. I can run SwingSet2 with
the same image so I assume it's something I'm not doing right with
respect to jtreg.
The dependency walker reports jvm.dll which is in bin\server. I tried
moving that to bin but that didn't help. Also some Win DLLs were
reported most of which start with API-MS-WIN- but I assume those are
false negatives. The sdk image I am testing is 32 bit and the DLL is
also 32 bit. Hopefully it's just something I don't yet understand about
jprt, like maybe a missing @ tag in the prolog.
Any ideas on how to debug this?
Pete
