<AWT Dev> Regression test failure loading a DLL
Pete Brunet
peter.brunet at oracle.com
Wed Dec 18 12:01:45 PST 2013
On 12/18/13 1:22 PM, Pete Brunet wrote:
> On 12/18/13 1:15 PM, Pete Brunet wrote:
>> On 12/18/13 3:24 AM, Artem Ananiev wrote:
>>> On 12/17/2013 10:42 PM, Pete Brunet wrote:
>>>> Hi Anthony, Thanks again for the assistance!
>>>>
>>>> On 12/17/13 7:29 AM, Anthony Petrov wrote:
>>>>>> Immediate load in JAWT*, delay load in Java*
>>>>> Why is that? Can you try re-linking the JAWTAccessBridge.DLL so that
>>>>> it uses delayed libs loading (which is always a good thing) and see if
>>>>> this changes anything?
>>>> Maybe it's a Dependency Walker anomaly? I got that info from the fact
>>>> that Dependency Walker shows an hour glass next to the red icon for
>>>> ole32.dll for Java*.dll but not for ole32.dll for JAWT*.dll. (Also when
>>>> I ran it today oleaut32.dll was delay load in both.) I looked through
>>>> the ole32.dll entries in the trees for both DLLs and didn't find any
>>>> differences.
>>>>
>>>> When I load JAWT*.dll Dependency Walker reports an error (and some
>>>> warnings). If I add bin\server to its search list that error goes away
>>>> (and the warnings remain).
>>>>
>>>> I found the build statements in jdk8\jdk\make\lib\PlatformLibraries.gmk
>>>> and Java* vs JAWT* are almost the same. Here is are the statments in
>>>> the gmk file for JAWT* and Java* with the two significant difference
>>>> noted.
>>>>
>>>> $(call SetupNativeCompilation,BUILD_JAWTACCESSBRIDGE$1, \
>>>> LIBRARY = JAWTAccessBridge$1, \
>>>> OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \
>>>> SRC := $(ACCESSBRIDGE_SRCDIR), \
>>>> INCLUDE_FILES := JAWTAccessBridge.cpp, \ <-- different list
>>>> for Java*
>>>> LANG := C++, \
>>>> OPTIMIZATION := LOW, \
>>>> CFLAGS := $(CFLAGS_JDKLIB) \
>>>> -DACCESSBRIDGE_ARCH_$3, \
>>>> LDFLAGS := $(LDFLAGS_JDKLIB) kernel32.lib user32.lib
>>>> gdi32.lib \
>>>> winspool.lib jawt.lib comdlg32.lib advapi32.lib
>>>> shell32.lib \ <-- jawt.lib added
>>> Let me ask a stupid question: does pre-loading jawt.dll before
>>> JAWTAccessBridge.dll help?
>> It didn't help but it's interesting that the failure now happens when
>> jawt.dll is loaded.
> Loading awt.dll before jawt.dll before JAWTAccessBridge-32.dll solved
> the problem. But why?
Normally JAWTAccessBridge-32.dll is loaded by this sequence: the access
bridge class is loaded by the VM (if the users's
.accessibility.properties is set up for that), then that class loads
JAWTAccessBridge-32.dll which I assume then loads jawt.dll which loads
awt.dll. The Win dll search algorithm found here:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx
looks in the app directory which I assume in the normal case has been
set to the jre's bin directory. In the case of running my test case
under jtreg the app directory and current directory are probably not the
jre's bin directory. So I suppose it's OK with respect to what I want
to accomplish with my test case for me to preload awt.dll and jawt.dll
in the test case.
>>>> ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib \
>>>> -subsystem:windows -machine:$2 \
>>>> -def:$(ACCESSBRIDGE_SRCDIR)/JAWTAccessBridge.DEF, \
>>>> VERSIONINFO_RESOURCE :=
>>>> $(ACCESSBRIDGE_SRCDIR)/AccessBridgeStatusWindow.rc, \
>>>> RC_FLAGS := $(RC_FLAGS), \
>>>> OBJECT_DIR := $(JDK_OUTPUTDIR)/objs/libjawtaccessbridge$1, \
>>>> DEBUG_SYMBOLS := true)
>>>>
>>>> $(call SetupNativeCompilation,BUILD_JAVAACCESSBRIDGE$1, \
>>>> LIBRARY = JavaAccessBridge$1, \
>>>> OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \
>>>> SRC := $(ACCESSBRIDGE_SRCDIR), \
>>>> INCLUDE_FILES := AccessBridgeATInstance.cpp
>>>> AccessBridgeDebug.cpp \
>>>> AccessBridgeJavaEntryPoints.cpp \
>>>> AccessBridgeMessages.cpp JavaAccessBridge.cpp, \
>>>> LANG := C++, \
>>>> OPTIMIZATION := LOW, \
>>>> CFLAGS := $(CFLAGS_JDKLIB) \
>>>> -DACCESSBRIDGE_ARCH_$3, \
>>>> LDFLAGS := $(LDFLAGS_JDKLIB) kernel32.lib user32.lib
>>>> gdi32.lib \
>>>> winspool.lib comdlg32.lib advapi32.lib shell32.lib \
>>>> ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib \
>>>> -subsystem:windows -machine:$2 \
>>>> -def:$(ACCESSBRIDGE_SRCDIR)/JavaAccessBridge.DEF, \
>>>> VERSIONINFO_RESOURCE :=
>>>> $(ACCESSBRIDGE_SRCDIR)/AccessBridgeStatusWindow.rc, \
>>>> RC_FLAGS := $(RC_FLAGS), \
>>>> OBJECT_DIR := $(JDK_OUTPUTDIR)/objs/libjavaaccessbridge$1, \
>>>> DEBUG_SYMBOLS := true)
>>>>
>>>> I wonder if the LDFLAGS lists are right. Dependency Walker shows the
>>>> first level dependencies as follows:
>>>> - JAWT*.dll: jawt.dll, msvcr100.dll, kernel32.dll
>>>> - Java*.dll: msvcr100.dll, kernel32.dll, user32.dll
>>>> but the LDFLAGS lists are much longer and also both are missing
>>>> msvcr100.lib
>>> msvcr100.dll is loaded by Java launcher from JRE/bin directory, so
>>> it's not a problem.
>>>
>>>> I ran the make in debug mode to get more output and the linker flags are
>>>> the same, except for the former including jawt.lib
>>>>
>>>> For JAWT*:
>>>> LDFLAGS := -nologo -opt:ref -incremental:no -safeseh -debug -dll
>>>> -libpath:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/jdk/lib
>>>>
>>>> kernel32.lib user32.lib gdi32.lib winspool.lib jawt.lib comdlg32.lib
>>>> advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib
>>>> odbccp32.lib -subsystem:windows -machine:I386
>>>> -def:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/jdk/src/closed/windows/native/sun/bridge/JAWTAccessBridge.DEF
>>>>
>>>>
>>>> For Java*:
>>>> LDFLAGS := -nologo -opt:ref -incremental:no -safeseh -debug -dll
>>>> -libpath:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/jdk/lib
>>>>
>>>> kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib
>>>> shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
>>>> -subsystem:windows -machine:I386
>>>> -def:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/jdk/src/closed/windows/native/sun/bridge/JavaAccessBridge.DEF
>>>>
>>>>
>>>> Note that some builds have a LDFLAGS_SUFFIX_windows with -DELAYLOAD, but
>>>> these bridge builds don't. I'll try adding this after lunch.
>>>>
>>>> Regarding the source code JAWTAccessBridge.cpp doesn't load any DLLs.
>>>> JavaAccessBridge.cpp has a loadlibrary of jawt.dll (and none of the
>>>> other included source files load DLLs).
>>>>
>>>> In the middle of all these details I don't want to loose track of the
>>>> fact that the problem only occurs when using jtreg. In normal use there
>>>> has never been a problem.
>>>>> Also,
>>>>>> API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-WINRT-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
>>> These dependencies are also fine, at least I see the same dlls in the
>>> list of awt.dll dependencies, and it doesn't cause any troubles.
>>>
>>>>> JDK doesn't support WinRT currently. The JAWT* (or any binary in JDK)
>>>>> just shouldn't be linked against these libraries (and probably other
>>>>> API-MS-*, too). Where do the dependencies come from? What does your
>>>>> Makefile do to link the JAWT* lib?
>>>> The JAWT* questions is answered above.
>>>>
>>>> This is the tree I see for the WinRT DLLs you mentioned:
>>>> javaaccessbridge.dll
>>>> user32.dll
>>>> advapi32.dll
>>>> wintrust.dll
>>>> crypt32.dll
>>>> userenv.dll
>>>> shell32.dll
>>>> wininet.dll
>>>> iertutil.dll
>>>> API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL and
>>>> API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
>>>>
>>>> ditto to
>>>> shell32.dll
>>>> shdocvw.dll
>>>> ieframe.dll
>>>> mshtml.dll
>>>> API-MS-WIN-CORE-WINRT-L1-1-0.DLL and
>>>> API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
>>> Thanks,
>>>
>>> Artem
>>>
>>>>> --
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>> On 12/17/2013 12:44 AM, Pete Brunet wrote:
>>>>>> Hi Anthony, Thanks for helping...
>>>>>>
>>>>>> On 12/16/13 1:32 PM, Anthony Petrov wrote:
>>>>>>> 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?
>>>>>> Differences:
>>>>>>
>>>>>> JAWT* has these extras
>>>>>> jvm.dll - error opening file
>>>>>> awt.dll - no problem with this and the following
>>>>>> java.dll
>>>>>> jawt.dll
>>>>>> verify.dll
>>>>>>
>>>>>> Immediate load in JAWT*, delay load in Java*
>>>>>> ole32 - colored red, i.e. missing export function required by parent
>>>>>> module
>>>>>> oleaut32.dll - no problem
>>>>>>> 2. If you change the order of loading the libraries, will it fail
>>>>>>> right away w/o even loading the JavaAccessBridge.dll ?
>>>>>> yes
>>>>>>> 3. If the above doesn't help, please post the full list of
>>>>>>> dependencies for JAWTAccessBridge.DLL as reported by the Dependency
>>>>>>> Walker.
>>>>>> Error opening file:
>>>>>> JVM.DLL
>>>>>> API-MS-WIN-CORE-COM-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-WINRT-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
>>>>>> API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
>>>>>> DCOMP.DLL
>>>>>> GPSVC.DLL
>>>>>> IESHIMS.DLL
>>>>>> Red (missing export function required by parent module):
>>>>>> API-MS-WIN-CORE-THREADPOOL-L1-1-0.DLL
>>>>>> OLE32.DLL
>>>>>> Red, delay load:
>>>>>> DWMAPI.DLL
>>>>>> IEFRAME.DLL
>>>>>> IMM32.DLL
>>>>>> MFPLAT.DLL
>>>>>> NDFAPI.DLL
>>>>>> USERENV.DLL
>>>>>> UXTHEME.DLL
>>>>>> No problems:
>>>>>> ADVAPI32.DLL
>>>>>> API-MS-WIN-CORE-CONSOLE-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-DATETIME-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-DEBUG-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-DELAYLOAD-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-ERRORHANDLING-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-FIBERS-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-FILE-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-HANDLE-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-HEAP-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-INTERLOCKED-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-IO-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-LIBRARYLOADER-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-LOCALIZATION-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-LOCALREGISTRY-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-MEMORY-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-MISC-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-NAMEDPIPE-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-PROCESSENVIRONMENT-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-PROCESSTHREADS-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-PROFILE-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-RTLSUPPORT-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-STRING-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-SYNCH-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-SYSINFO-L1-1-0.DLL
>>>>>> API-MS-WIN-CORE-UTIL-L1-1-0.DLL
>>>>>> API-MS-WIN-SECURITY-BASE-L1-1-0.DLL
>>>>>> API-MS-WIN-SECURITY-LSALOOKUP-L1-1-0.DLL
>>>>>> API-MS-WIN-SERVICE-CORE-L1-1-0.DLL
>>>>>> API-MS-WIN-SERVICE-MANAGEMENT-L1-1-0.DLL
>>>>>> API-MS-WIN-SERVICE-MANAGEMENT-L2-1-0.DLL
>>>>>> API-MS-WIN-SERVICE-WINSVC-L1-1-0.DLL
>>>>>> AWT.DLL
>>>>>> CRYPTBASE.DLL
>>>>>> GDI32.DLL
>>>>>> JAVA.DLL
>>>>>> JAWT.DLL
>>>>>> JAWTACCESSBRIDGE.DLL
>>>>>> KERNEL32.DLL
>>>>>> KERNELBASE.DLL
>>>>>> LPK.DLL
>>>>>> MSVCR100.DLL
>>>>>> MSVCRT.DLL
>>>>>> NTDLL.DLL
>>>>>> OLEAUT32.DLL
>>>>>> RPCRT4.DLL
>>>>>> SSPICLI.DLL
>>>>>> USER32.DLL
>>>>>> USP10.DLL
>>>>>> VERIFY.DLL
>>>>>> ACLUI.DLL
>>>>>> ACTIVEDS.DLL
>>>>>> ADSLDPC.DLL
>>>>>> ADVPACK.DLL
>>>>>> API-MS-WIN-DOWNLEVEL-ADVAPI32-L1-1-0.DLL
>>>>>> API-MS-WIN-DOWNLEVEL-ADVAPI32-L2-1-0.DLL
>>>>>> API-MS-WIN-DOWNLEVEL-NORMALIZ-L1-1-0.DLL
>>>>>> API-MS-WIN-DOWNLEVEL-OLE32-L1-1-0.DLL
>>>>>> API-MS-WIN-DOWNLEVEL-SHELL32-L1-1-0.DLL
>>>>>> API-MS-WIN-DOWNLEVEL-SHLWAPI-L1-1-0.DLL
>>>>>> API-MS-WIN-DOWNLEVEL-SHLWAPI-L2-1-0.DLL
>>>>>> API-MS-WIN-DOWNLEVEL-USER32-L1-1-0.DLL
>>>>>> API-MS-WIN-DOWNLEVEL-VERSION-L1-1-0.DLL
>>>>>> API-MS-WIN-SECURITY-SDDL-L1-1-0.DLL
>>>>>> APPHELP.DLL
>>>>>> ATL.DLL
>>>>>> AUTHZ.DLL
>>>>>> AVRT.DLL
>>>>>> BCRYPT.DLL
>>>>>> BROWCLI.DLL
>>>>>> CABINET.DLL
>>>>>> CERTCLI.DLL
>>>>>> CERTENROLL.DLL
>>>>>> CFGMGR32.DLL
>>>>>> CLBCATQ.DLL
>>>>>> COMCTL32.DLL
>>>>>> COMCTL32.DLL
>>>>>> COMDLG32.DLL
>>>>>> CREDUI.DLL
>>>>>> CRYPT32.DLL
>>>>>> CRYPTSP.DLL
>>>>>> CRYPTUI.DLL
>>>>>> CSCAPI.DLL
>>>>>> D2D1.DLL
>>>>>> D3D11.DLL
>>>>>> DAVHLPR.DLL
>>>>>> DBGHELP.DLL
>>>>>> DEVMGR.DLL
>>>>>> DEVOBJ.DLL
>>>>>> DEVRTL.DLL
>>>>>> DFSCLI.DLL
>>>>>> DHCPCSVC.DLL
>>>>>> DHCPCSVC6.DLL
>>>>>> DNSAPI.DLL
>>>>>> DRVSTORE.DLL
>>>>>> DSROLE.DLL
>>>>>> DUI70.DLL
>>>>>> DUSER.DLL
>>>>>> DWRITE.DLL
>>>>>> DXGI.DLL
>>>>>> EAPPCFG.DLL
>>>>>> EAPPPRXY.DLL
>>>>>> EFSADU.DLL
>>>>>> EFSUTIL.DLL
>>>>>> ELSCORE.DLL
>>>>>> ESENT.DLL
>>>>>> FMS.DLL
>>>>>> GDIPLUS.DLL
>>>>>> GPAPI.DLL
>>>>>> HLINK.DLL
>>>>>> IEADVPACK.DLL
>>>>>> IERTUTIL.DLL
>>>>>> IEUI.DLL
>>>>>> IMAGEHLP.DLL
>>>>>> IMGUTIL.DLL
>>>>>> INETCOMM.DLL
>>>>>> IPHLPAPI.DLL
>>>>>> LINKINFO.DLL
>>>>>> LOGONCLI.DLL
>>>>>> MFC42U.DLL
>>>>>> MLANG.DLL
>>>>>> MMDEVAPI.DLL
>>>>>> MPR.DLL
>>>>>> MPRAPI.DLL
>>>>>> MPRMSG.DLL
>>>>>> MSASN1.DLL
>>>>>> MSCTF.DLL
>>>>>> MSFEEDS.DLL
>>>>>> MSHTML.DLL
>>>>>> MSI.DLL
>>>>>> MSILTCFG.DLL
>>>>>> MSIMG32.DLL
>>>>>> MSLS31.DLL
>>>>>> MSOERT2.DLL
>>>>>> MSRATING.DLL
>>>>>> MSSIGN32.DLL
>>>>>> NCRYPT.DLL
>>>>>> NETAPI32.DLL
>>>>>> NETBIOS.DLL
>>>>>> NETJOIN.DLL
>>>>>> NETPLWIZ.DLL
>>>>>> NETUTILS.DLL
>>>>>> NEWDEV.DLL
>>>>>> NORMALIZ.DLL
>>>>>> NSI.DLL
>>>>>> NTDSAPI.DLL
>>>>>> NTSHRUI.DLL
>>>>>> OCCACHE.DLL
>>>>>> ODBC32.DLL
>>>>>> OLEACC.DLL
>>>>>> OLEDLG.DLL
>>>>>> ONEX.DLL
>>>>>> PCWUM.DLL
>>>>>> POWRPROF.DLL
>>>>>> PRINTUI.DLL
>>>>>> PRNTVPT.DLL
>>>>>> PROFAPI.DLL
>>>>>> PROPSYS.DLL
>>>>>> PSAPI.DLL
>>>>>> PUIAPI.DLL
>>>>>> RASAPI32.DLL
>>>>>> RASDLG.DLL
>>>>>> RASMAN.DLL
>>>>>> REGAPI.DLL
>>>>>> RSTRTMGR.DLL
>>>>>> RTUTILS.DLL
>>>>>> SAMCLI.DLL
>>>>>> SAMLIB.DLL
>>>>>> SCECLI.DLL
>>>>>> SECUR32.DLL
>>>>>> SENSAPI.DLL
>>>>>> SETUPAPI.DLL
>>>>>> SHDOCVW.DLL
>>>>>> SHELL32.DLL
>>>>>> SHLWAPI.DLL
>>>>>> SLC.DLL
>>>>>> SPFILEQ.DLL
>>>>>> SPINF.DLL
>>>>>> SPPC.DLL
>>>>>> SRVCLI.DLL
>>>>>> TAPI32.DLL
>>>>>> UIAUTOMATIONCORE.DLL
>>>>>> URLMON.DLL
>>>>>> VAULTCLI.DLL
>>>>>> VERSION.DLL
>>>>>> VPNIKEAPI.DLL
>>>>>> W32TOPL.DLL
>>>>>> WDI.DLL
>>>>>> WEBIO.DLL
>>>>>> WEBSERVICES.DLL
>>>>>> WER.DLL
>>>>>> WERUI.DLL
>>>>>> WINBRAND.DLL
>>>>>> WINDOWSCODECS.DLL
>>>>>> WINHTTP.DLL
>>>>>> WININET.DLL
>>>>>> WINMM.DLL
>>>>>> WINNSI.DLL
>>>>>> WINSCARD.DLL
>>>>>> WINSPOOL.DRV
>>>>>> WINSTA.DLL
>>>>>> WINTRUST.DLL
>>>>>> WKSCLI.DLL
>>>>>> WLANAPI.DLL
>>>>>> WLANUTIL.DLL
>>>>>> WLDAP32.DLL
>>>>>> WS2_32.DLL
>>>>>> WTSAPI32.DLL
>>>>>> XMLLITE.DLL
>>>>>>> --
>>>>>>> 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
>>>>>>>>
>>>>>>>>
More information about the awt-dev
mailing list