<AWT Dev> Regression test failure loading a DLL

Pete Brunet peter.brunet at oracle.com
Wed Dec 18 11:22:42 PST 2013


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?
>>>                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