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