<AWT Dev> Regression test failure loading a DLL
Artem Ananiev
artem.ananiev at oracle.com
Wed Dec 18 01:24:04 PST 2013
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?
> 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