Send again. And BTW, JPRT runs fine. 在 Jun 23, 2013，6:29 PM，Weijun Wang <weijun.w...@oracle.com> 写道：
> The macosx problem found, the machine's native GSS does not support shared > replaycache. > > *Valerie* and/or *Xuelei*, can you please review the fix? > > http://cr.openjdk.java.net/~weijun/8017453/webrev.00/ > > So interop (between Java and native) will not run on Windows and Mac now. It > still tests shared replaycache between Java processes. > > The left problem is linux-i586 test running on a x64 machine. Either we can > install i386 libraries (ia32-libs for Ubuntu) or disallow 32 bit tests on 64 > bit systems. > > I'm running JPRT now. > > Thanks > Max > > > On 6/22/2013 11:17 PM, Weijun Wang wrote: >> >> >> On 6/22/13 4:48 PM, Weijun Wang wrote: >>> I've found some reasons. There are several kinds of failures: >>> >>> 1. macosx. Reason not known yet. >>> >>> 2. windows. Tests should not run at all. >> >> Will not call native GSS on Windows. >> >>> >>> 3. linux-i586. Even an existing native GSS test fails. This is probably >>> the case we need to update the system. It's also possible the earlier >>> rcache failure triggers this one, but not likely. >> >> The machine is a x86_64 and it has >> /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2. But the test is linux-i586. >> >> Maybe we should only test linux-i586 on x86 machines? >> >>> >>> 4. solaris-sparc. The failure is not the interop test, but a pure Java >>> one (also added in this changeset). Should be easy to evaluate. >> >> That machine has a /etc/krb5.conf which sets "clockskew = 3600", quite >> huge value. I'll add a krb5.conf to the test to override it. >> >> So the last one to check is the macosx one. If I cannot solve the >> problem on Sunday, will problem-list it. >> >> Thanks >> Max >> >>> >>> I made a final code update (due to CCC update, change environment >>> variable to system property) and haven't run JPRT after that. I thought >>> it's small. At least #2 above is because of this. :-( >>> >>> Thanks >>> Max >>>
