Re: [kaffe] does kaffe support sun jsse officially?
Hi Joon, --- Â÷ÁØÇõ [EMAIL PROTECTED] wrote: Hi there. I'm still trying to run jsse with kaffe. But it's not easy to me.-.-; When I run a sample program with debuging mode, the following error is printed. -- keyStore is : keyStore type is : JKS init keystore default context init failed: java.security.PrivilegedActionException java.net.SocketException: SSL implementation not available at java.lang.Throwable.fillInStackTrace(Throwable.java:native) at java.lang.Throwable.init(Throwable.java:38) at java.lang.Exception.init(Exception.java:24) at java.io.IOException.init(IOException.java:24) at java.net.SocketException.init(SocketException.java:21) at javax.net.ssl.DefaultSSLSocketFactory.createSocket(DashoA6275:line unknown, pc 0x819f3c5) at SSLSocketClient.main(SSLSocketClient.java:41) -- I've got that far as well. I think that the error is occured when the program initializes keystore. From sun java site, the error, SSL implementation not available, can be occured when there was a problem with SSLContext initialization, for example due to a corrupted keystore. (Note: One vendor has shipped a keystore in an unknown format, and that may cause this type of error.) And the solusion is Check initialization parameters. Ensure any keystores specified are valid (e.g., by trying to use the keytool to examine them). Sun's JSSE documentation is not very helpful in that respect. But then, their JSSE has never been supposed to be run on other VMs anyway, I assume. One needs Sun's own provider in order to be able to provide an algorithm to read keystores in the default, proprietary format, JKS. The algorithm is in Sun's JDK's rt.jar. I've tried adding sun's rt.jar from jdk 1.3 to kaffe's bootclasspath, as well as setting security providers to sun's providers only, and added the j*.jar files from the jsse distribution to kaffe's bootclasspath. Then I got much further: bash-2.05a$ kaffe -Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol -cp ../../lib/jnet.jar:../../lib/jsse.jar:../../lib/jcert.jar -Djavax.net.debug=all URLReader [snip] verify exception was: java.lang.ClassCastException: can't cast `com/sun/net/ssl/internal/ssl/JSA_SHA1RSASignature' to `java/security/Signature' main, SEND SSL v3.0 ALERT: fatal, description = certificate_unknown main, WRITE: SSL v3.0 Alert, length = 2 javax.net.ssl.SSLException: untrusted server cert chain at java.lang.Throwable.fillInStackTrace(Throwable.java:native) at java.lang.Throwable.init(Throwable.java:44) at java.lang.Exception.init(Exception.java:24) at java.io.IOException.init(IOException.java:24) at javax.net.ssl.SSLException.init(DashoA6275:line unknown, pc 0x86d8ba6) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275:line unknown, pc 0x868c1ad) at com.sun.net.ssl.internal.ssl.ClientHandshaker.a(DashoA6275:line unknown, pc 0x86c9c17) at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(DashoA6275:line unknown, pc 0x84844ef) at com.sun.net.ssl.internal.ssl.Handshaker.process_record(DashoA6275:line unknown, pc 0x82fd5ca) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275:line unknown, pc 0x84a1855) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275:line unknown, pc 0x845c394) at com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA6275:line unknown, pc 0x845eef8) at java.io.OutputStream.write(OutputStream.java:24) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(DashoA6275:line unknown, pc 0x832bcf3) at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.doConnect(DashoA6275:line unknown, pc 0x84195de) at com.sun.net.ssl.internal.www.protocol.https.NetworkClient.openServer(DashoA6275:line unknown, pc 0x83b1468) at com.sun.net.ssl.internal.www.protocol.https.HttpClient.l(DashoA6275:line unknown, pc 0x83eba76) at com.sun.net.ssl.internal.www.protocol.https.HttpClient.init(DashoA6275:line unknown, pc 0x8402427) at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.init(DashoA6275:line unknown, pc 0x839ec02) at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.a(DashoA6275:line unknown, pc 0x83f18bd) at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.a(DashoA6275:line unknown, pc 0x8380463) at com.sun.net.ssl.internal.www.protocol.https.HttpsURLConnection.connect(DashoA6275:line unknown, pc 0x838682e) at java.net.URL.openConnection(URL.java:247) at java.net.URL.openStream(URL.java:255) at URLReader.main(URLReader.java:39) I think trying to debug Sun's obfuscated (that's where the DashO-s come from) code is a waste of
[kaffe] Re: 'it is in the way' error
On Mon, 28 Apr 2003 16:56:26 +0900 (JST), Kiyo Inaba [EMAIL PROTECTED] said: I am not a CVS expert, but from last Friday (maybe), cvs.kaffe.org may miss some files. [snip!] And if you try to update that directory, some thing like C kaffe/kaffe/kaffevm/jit/registers.h cvs checkout: move away kaffe/kaffe/kaffevm/jit/seq.c; it is in the way occurs. This is caused with you having a file in your workspace, with the same name (or so CVS thinks) as one that has been added to CVS repository. One place this happens is if you work on Windows, and someone working on UNIX/linux/FreeBSD/etc. checks in a file with the same name as an already existing file, except for different case. Eg. if you already had a seg.c and then someone added a seq.C, you might see this. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] build failure if old version present, ServletContext.setAttribute
Hi Greg, --- Greg Wooledge [EMAIL PROTECTED] wrote: assertion blk-free != 0 failed: file mem/gc-mem.c, line 324 Does running with -vmdebug GCDIAG help to provoke it faster? cheers, dalibor topic __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] sysdepCallMethod() tests galore
--- Gwenole Beauchesne [EMAIL PROTECTED] wrote: On Fri, 16 May 2003, Timothy Stack wrote: I'd like to add this to the test/internal directory, but I need to know what a correct run is supposed to look like. Can you send what the output is supposed to look like, or better, make the test do the checks itself with assert(). OK, I updated the tests with a few checks against the returned value through sysdepCallMethod, then abort() if that differs. Steps to reproduce: - Kaffe is configured - Be in developers, and sh ./test_sysdepCallMethod.c ;-) - ./test_sysdepCallMethod after the sh step, I get a ./test_sysdepCallMethod^M file. running it produces the following message: bash-2.05a$ ./test_sysdepCallMethod^M # f_v_v: = v returns: void returns: void [snip] # add_2j: j, 1, j, 2 = j 1, 2 returns: 3 8589934593, 4294967297 returns: 12884901890Aborted I assume it may have something to do with the garbled name? cheers, dalibor topic __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Kaffe CVS: kaffe kaz
CVSROOT:/cvs/kaffe Module name:kaffe Changes by: kaz 03/05/28 11:15:46 Modified files: . : ChangeLog libraries/javalib: Makefile.in libraries/javalib/gnu/java/nio: SelectionKeyImpl.java SocketChannelImpl.java libraries/javalib/java/nio: Buffer.java ByteBuffer.java CharBuffer.java DoubleBuffer.java FloatBuffer.java IntBuffer.java LongBuffer.java ShortBuffer.java Added files: libraries/javalib/java/nio: ByteBufferImpl.java CharBufferImpl.java CharViewBufferImpl.java DirectByteBufferImpl.java DoubleBufferImpl.java DoubleViewBufferImpl.java FloatBufferImpl.java FloatViewBufferImpl.java IntBufferImpl.java IntViewBufferImpl.java LongBufferImpl.java LongViewBufferImpl.java ShortBufferImpl.java ShortViewBufferImpl.java Log message: 2003-05-28 Ito Kazumitsu [EMAIL PROTECTED] * libraries/javalib/Makefile.in: added gnu_classpath_SRCS required for compiling java/nio/* and gnu/java/nio/*.java * java/nio/Buffer.java, java/nio/ByteBuffer.java, java/nio/CharBuffer.java, java/nio/DoubleBuffer.java, java/nio/FloatBuffer.java, java/nio/IntBuffer.java, java/nio/LongBuffer.java, java/nio/ShortBuffer.java, gnu/java/nio/SelectionKeyImpl.java, gnu/java/nio/SocketChannelImpl.java Resynced with GNU Classpath. * java/nio/ByteBufferImpl.java, java/nio/CharBufferImpl.java, java/nio/CharViewBufferImpl.java, java/nio/DirectByteBufferImpl.java, java/nio/DoubleBufferImpl.java, java/nio/DoubleViewBufferImpl.java, java/nio/FloatBufferImpl.java, java/nio/FloatViewBufferImpl.java, java/nio/IntBufferImpl.java, java/nio/IntViewBufferImpl.java, java/nio/LongBufferImpl.java, java/nio/LongViewBufferImpl.java, java/nio/ShortBufferImpl.java, java/nio/ShortViewBufferImpl.java New files copied from GNU Classpath ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Saxon does not work with the CVS version of kaffe
: == Dalibor Topic [EMAIL PROTECTED] writes: : --- Ito Kazumitsu [EMAIL PROTECTED] wrote: Studying this case, I found some bugs in GNU Classpath's java/nio/CharBuffer.java and java/nio/Buffer.java GNU Classpath's java/nio and gnu/java/nio files have been fixed. So I have just merged them into kaffe. : Since Daniel discovered problems with the Collection classes I merged in from : Classpath, I assume that this might have something to do with it as well. Could : you revert the collection classes to the previous version and try again? It seems collection classes have nothing to do with my case. Just updating java/nio/* and gnu/java/nio/* had a good effect for me. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Makefile for java.nio
Hi, I'm trying to compile the latest version of Kaffe from CVS. The build of the libraries fails with several errors, like: java/nio/LongBuffer.java:80: error:Cannot find class LongBufferImpl [JLS 8] It seems that some (new?) files are missing from the list in the Makefile for the libraries (or is/should this list be automatically generated). Could somebody fix this? I'll try to find a workaround (I don't use nio anyway). Cheers, Daniel ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: Makefile for java.nio
Actually, it might not be that the classes are missing. It is that the compiler (kjc) finds errors in them (so they probably get ignored after that). Although I'm not sure, because there are both java.nio.*Impl and gnu.java.nio.*Impl. There might be two separate issues. Or could it be a kjc bug? I'll try with jikes. The build starts with: Compiling classes from @essential.files using /usr/local/src/kaffe/kaffe/kaffe/kaffe-bin -verbosegc at.dms.kjc.Main The relevant error messages are: gnu/java/nio/CharBufferImpl.java:55: error:Cannot find field backing_buffer [JLS 15.11] gnu/java/nio/CharBufferImpl.java:62: error:Cannot find field backing_buffer [JLS 15.11] gnu/java/nio/CharBufferImpl.java:69: error:Variable backing_buffer is not defined in current context gnu/java/nio/CharBufferImpl.java:78: error:Cannot find field backing_buffer [JLS 15.11] gnu/java/nio/CharBufferImpl.java:199: error:Variable backing_buffer is not defined in current context gnu/java/nio/CharBufferImpl.java:179: error:Variable backing_buffer is not defined in current context gnu/java/nio/CharBufferImpl.java:173: error:Method get must return a value [JLS 8.4.5] gnu/java/nio/CharBufferImpl.java:162: error:Variable backing_buffer is not defined in current context gnu/java/nio/CharBufferImpl.java:146: error:Variable backing_buffer is not defined in current context gnu/java/nio/CharBufferImpl.java:148: error:Local variable e may have not been initialized before use [JLS 14.4] gnu/java/nio/CharBufferImpl.java:144: error:Method get must return a value [JLS 8.4.5] gnu/java/nio/CharBufferImpl.java:101: error:Variable backing_buffer is not defined in current context gnu/java/nio/CharBufferImpl.java:99: error:Method slice must return a value [JLS 8.4.5] gnu/java/nio/CharBufferImpl.java:88: error:Variable backing_buffer is not defined in current context gnu/java/nio/CharBufferImpl.java:89: error:Local variable res may have not been initialized before use [JLS 14.4] gnu/java/nio/CharBufferImpl.java:90: error:Local variable res may have not been initialized before use [JLS 14.4] gnu/java/nio/CharBufferImpl.java:86: error:Method asByteBuffer must return a value [JLS 8.4.5] [ checked body of gnu/java/nio/CharBufferImpl.java in 129 ms ] gnu/java/nio/DoubleBufferImpl.java:55: error:Cannot find field backing_buffer [JLS 15.11] gnu/java/nio/DoubleBufferImpl.java:62: error:Cannot find field backing_buffer [JLS 15.11] gnu/java/nio/DoubleBufferImpl.java:69: error:Variable backing_buffer is not defined in current context gnu/java/nio/DoubleBufferImpl.java:76: error:Cannot find field backing_buffer [JLS 15.11] gnu/java/nio/DoubleBufferImpl.java:152: error:Variable backing_buffer is not defined in current context gnu/java/nio/DoubleBufferImpl.java:144: error:Variable backing_buffer is not defined in current context gnu/java/nio/DoubleBufferImpl.java:142: error:Method get must return a value [JLS 8.4.5] gnu/java/nio/DoubleBufferImpl.java:137: error:Variable backing_buffer is not defined in current context gnu/java/nio/DoubleBufferImpl.java:127: error:Variable backing_buffer is not defined in current context gnu/java/nio/DoubleBufferImpl.java:129: error:Local variable e may have not been initialized before use [JLS 14.4] gnu/java/nio/DoubleBufferImpl.java:125: error:Method get must return a value [JLS 8.4.5] gnu/java/nio/DoubleBufferImpl.java:86: error:Variable backing_buffer is not defined in current context gnu/java/nio/DoubleBufferImpl.java:87: error:Local variable res may have not been initialized before use [JLS 14.4] gnu/java/nio/DoubleBufferImpl.java:88: error:Local variable res may have not been initialized before use [JLS 14.4] gnu/java/nio/DoubleBufferImpl.java:84: error:Method asByteBuffer must return a value [JLS 8.4.5] [ checked body of gnu/java/nio/DoubleBufferImpl.java in 82 ms ] gnu/java/nio/LongBufferImpl.java:55: error:Cannot find field backing_buffer [JLS 15.11] gnu/java/nio/LongBufferImpl.java:62: error:Cannot find field backing_buffer [JLS 15.11] gnu/java/nio/LongBufferImpl.java:69: error:Variable backing_buffer is not defined in current context gnu/java/nio/LongBufferImpl.java:78: error:Cannot find field backing_buffer [JLS 15.11] gnu/java/nio/LongBufferImpl.java:152: error:Variable backing_buffer is not defined in current context gnu/java/nio/LongBufferImpl.java:144: error:Variable backing_buffer is not defined in current context gnu/java/nio/LongBufferImpl.java:142: error:Method get must return a value [JLS 8.4.5] gnu/java/nio/LongBufferImpl.java:137: error:Variable backing_buffer is not defined in current context gnu/java/nio/LongBufferImpl.java:127: error:Variable backing_buffer is not defined in current context gnu/java/nio/LongBufferImpl.java:129: error:Local variable e may have not been initialized before use [JLS 14.4] gnu/java/nio/LongBufferImpl.java:125: error:Method get must return a value [JLS 8.4.5] gnu/java/nio/LongBufferImpl.java:88: error:Variable backing_buffer is not defined
[kaffe] Re: Makefile for java.nio
The build also fails with jikes: Found 11 semantic errors compiling gnu/java/nio/CharBufferImpl.java: 55. this.backing_buffer = new char [cap]; ^^ *** Semantic Error: The field backing_buffer in type java.nio.CharBuffer has default access and is not accessible here. 62. this.backing_buffer = array; ^^ *** Semantic Error: The field backing_buffer in type java.nio.CharBuffer has default access and is not accessible here. etc ... Could the person who fixes this send me a mail (I am not on the list). Thanks, Daniel ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Kaffe CVS: kaffe dalibor
CVSROOT:/cvs/kaffe Module name:kaffe Changes by: dalibor 03/05/28 13:57:54 Modified files: . : ChangeLog developers : autogen.sh kaffe/scripts : Makefile.in kaffe/scripts/compat: Makefile.in libraries/javalib: Makefile.am Makefile.in libraries/javalib/profiles/allatonce: all.files libraries/javalib/profiles/default: nio.files Removed files: libraries/javalib/gnu/java/nio: ByteBufferImpl.java CharBufferImpl.java DoubleBufferImpl.java FloatBufferImpl.java IntBufferImpl.java LongBufferImpl.java ShortBufferImpl.java Log message: 2003-05-28 Dalibor Topic [EMAIL PROTECTED] * developers/autogen.sh: uncommented class file list updating since it works again on Mandrake 9.1. * libraries/javalib/gnu/java/nio/ByteBufferImpl.java, libraries/javalib/gnu/java/nio/CharBufferImpl.java, libraries/javalib/gnu/java/nio/DoubleBufferImpl.java, libraries/javalib/gnu/java/nio/FloatBufferImpl.java, libraries/javalib/gnu/java/nio/IntBufferImpl.java, libraries/javalib/gnu/java/nio/LongBufferImpl.java, libraries/javalib/gnu/java/nio/ShortBufferImpl.java: removed. * libraries/javalib/Makefile.am: libraries/javalib/profiles/allatonce/all.files, libraries/javalib/profiles/default/nio.files, updated to reflect class library changes. * kaffe/scripts/compat/Makefile.in, kaffe/scripts/Makefile.in, libraries/javalib/Makefile.in: regenerated. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: Makefile for java.nio
Salut Daniel, --- Daniel Bonniot [EMAIL PROTECTED] wrote: The build also fails with jikes: Found 11 semantic errors compiling gnu/java/nio/CharBufferImpl.java: 55. this.backing_buffer = new char [cap]; ^^ *** Semantic Error: The field backing_buffer in type java.nio.CharBuffer has default access and is not accessible here. 62. this.backing_buffer = array; ^^ *** Semantic Error: The field backing_buffer in type java.nio.CharBuffer has default access and is not accessible here. etc ... Could the person who fixes this send me a mail (I am not on the list). I haven't tried it with jikes yet, but I've just checked in a fix that worked for me on kjc. cheers, dalibor topic __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Testing for 1.1.0 release
hi Stuart, --- Stuart Ballard [EMAIL PROTECTED] wrote: Stuart Ballard wrote: Dalibor Topic wrote: Okay, well, the test is attached. The purpose of the test is to verify that the implementations of all concrete methods in Abstract* are implemented the same way in terms of which virtual methods they call on their subclasses. This ensures (hopefully) that when client code subclasses Abstract* directly and overrides certain methods, the behavior will be the same between Sun's implementation and ours. I have no idea how close any free implementation comes to passing this test, because I've never tried! Did anyone happen to try this test? I'm really curious to know what the results are like... I gave it a short spin on tha same day, and the diff between kaffe and jdk 1.4 was quite large. I decided to postpone further invertigation until the transition to claspath's collections is completed. cheers, dalibor topic __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Kaffe CVS: kaffe kaz
CVSROOT:/cvs/kaffe Module name:kaffe Changes by: kaz 03/05/28 15:55:54 Modified files: . : ChangeLog libraries/javalib: Makefile.in Log message: 2003-05-28 Ito Kazumitsu [EMAIL PROTECTED] * libraries/javalib/Makefile.in: add new java/nio files to java_nio_SRCS ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: Makefile for java.nio
I haven't tried it with jikes yet, but I've just checked in a fix that worked for me on kjc. Thanks, it works with jikes too. So I can now report that kaffe built correctly, and make check reports no error (only TestNative.java was SKIP'ed, is that normal?). Furthermore, it could by used to bootstrap my Nice compiler (http://nice.sf.net). So as far as I am concerned, kaffe 1.1 can be released ;-) What are the plans when approaching the release (still on June 1st?). Will there be a release candidate? A CVS freeze, so people can do a last test? Cheers, Daniel PS: Dalibor, I saw in CVS that you wrote FAQ.mauve, thanks. It did not appear yet on the web site, though. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Makefile for java.nio
- == Ito Kazumitsu [EMAIL PROTECTED] writes: : == Daniel Bonniot [EMAIL PROTECTED] writes: - : I'm trying to compile the latest version of Kaffe from CVS. - : The build of the libraries fails with several errors, like: - : java/nio/LongBuffer.java:80: error:Cannot find class LongBufferImpl - : [JLS 8] - - I am verry sorry. I forgot to add new files to libraries/javalib/Makefile.in Dalibor, I am sorry for making trouble about java/nio/*. But could you please look into it? ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Makefile for java.nio
I am verry sorry. I forgot to add new files to libraries/javalib/Makefile.in when I copied some files from GNU Classpath. Please get the newest version of Kaffe from CVS and try again. Thanks a lot. Surprisingly, it seemed to work even without that (it was the old files in gnu.java.nio that failed to compile, and that Dalibor removed). I don't know enough about Kaffe's build to know why. Is it really necessary to list all source files in the Makefile? Daniel ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] build failure if old version present, ServletContext.setAttribute
Dalibor Topic ([EMAIL PROTECTED]) wrote: assertion blk-free != 0 failed: file mem/gc-mem.c, line 324 Does running with -vmdebug GCDIAG help to provoke it faster? I had to rebuild with --enable-debug $ time java -vmdebug GCDIAG freenet.node.Main assertion gc_heap_isobject(info, unit) failed: file mem/gc-incremental.c, line 259 Abort (core dumped) 1.91s real 1.73s user 0.12s system $ time java freenet.node.Main Illegal instruction (core dumped) 97.39s real35.61s user 2.57s system Here's the core dump backtrace for the second one: #0 0x401cb0bd in getaddrinfo () #1 0x401cb5fd in getaddrinfo () #2 0x401cb3a9 in getaddrinfo () #3 0x401ca9fb in getaddrinfo () #4 0x401c9a58 in getaddrinfo () #5 0x401c98d3 in getaddrinfo () #6 0x407e8543 in java_net_NativeInetAddressImpl_lookupAllHostAddr0 ( none=0x417ff0, jStr=0x25f4dc8) at InetAddressImpl.c:160 #7 0x46323d in ?? () #8 0x43855b in ?? () #9 0x466218 in ?? () #10 0x465239 in ?? () #11 0x1502471 in ?? () #12 0xa5d641 in ?? () #13 0x22a12ea in ?? () #14 0xab22d6 in ?? () #15 0x400591a2 in callMethodV (meth=0xa31880, func=0xab2010, obj=0x1a98c20, args=0x1e0df94 [EMAIL PROTECTED]@[EMAIL PROTECTED]@¼¼\t@, ret=0x1e0dbec) at ../../config/i386/common.h:38 #16 0x400452d5 in Kaffe_CallVoidMethodV (env=0x4009617c, obj=0x1a98c20, meth=0xa31880, args=0x1e0df94 [EMAIL PROTECTED]@[EMAIL PROTECTED]@¼¼\t@) at jni.c:1094 #17 0x40045372 in Kaffe_CallVoidMethod (env=0x4009617c, obj=0x1a98c20, meth=0xa31880) at jni.c:1107 #18 0x4005a17c in firstStartThread (arg=0x1a98c20) at thread.c:357 #19 0x40083394 in start_this_sucker_on_a_new_frame () at jthread.c:1266 #20 0x40083514 in jthread_create (pri=596, func=0, daemon=1000, jlThread=0x196f960, threadStackSize=0) at jthread.c:1336 So I ran it again: $ time java freenet.node.Main assertion !INTS_DISABLED() failed: file exception.c, line 398 Abort (core dumped) 66.19s real32.22s user 2.16s system #0 0x401f327b in kill () #1 0x401f2bd7 in abort () #2 0x401adf53 in __assert () #3 0x400372fc in dispatchException (eobj=0x1f0d638, baseframe=0x19d1e98) at exception.c:398 #4 0x40037594 in floatingException (frame=0x1c8e38) at exception.c:542 #5 0x4008642c in nullException (sig=11, code=1871528, ctx=0x1c8e58) at signal.c:87 #6 0x40009004 in ?? () #7 0x40059f50 in startSpecialThread (arg=0x1a34b0) at thread.c:274 #8 0x40083394 in start_this_sucker_on_a_new_frame () at jthread.c:1266 #9 0x40083514 in jthread_create (pri=11, func=0x40059f1c startSpecialThread, daemon=-809511144, jlThread=0x40059c19, threadStackSize=1074109355) at jthread.c:1336 #10 0x40059bf8 in createThread (tid=0x1a34b0, func=0x40059f1c, stacksize=16384, einfo=0xcfbfd798) at thread.c:121 #11 0x4005a032 in createDaemon (func=0x4003b23c, nm=0x4003c8eb gc, arg=0x4009acac, prio=11, stacksize=16384, einfo=0xcfbfd798) at thread.c:313 #12 0x4003c981 in gcEnable (collector=0x4009acac) at mem/gc-incremental.c:1093 #13 0x40027610 in initialiseKaffe () at baseClasses.c:214 #14 0x40041abb in JNI_CreateJavaVM (vm=0x9310, env=0x9488, args=0x9318) at jni.c:205 Good luck. -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | pgp0.pgp Description: PGP signature
RE: [kaffe] does kaffe support sun jsse officially?
Hi Dalibor Topic. Thnk you for your detailed reply. :) I'm happy to read your helpful information. I'll check out what you mentioned. Have a nice day. Joon Hyuk Cha. -Original Message- From: Dalibor Topic [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 28, 2003 11:52 PM $)CTo: BwAXGu; '[EMAIL PROTECTED]' Subject: Re: [kaffe] does kaffe support sun jsse officially? Hi Joon, --- BwAXGu [EMAIL PROTECTED] wrote: Hi there. I'm still trying to run jsse with kaffe. But it's not easy to me.-.-; When I run a sample program with debuging mode, the following error is printed. -- -- -- keyStore is : keyStore type is : JKS init keystore default context init failed: java.security.PrivilegedActionException java.net.SocketException: SSL implementation not available at java.lang.Throwable.fillInStackTrace(Throwable.java:native) at java.lang.Throwable.init(Throwable.java:38) at java.lang.Exception.init(Exception.java:24) at java.io.IOException.init(IOException.java:24) at java.net.SocketException.init(SocketException.java:21) at javax.net.ssl.DefaultSSLSocketFactory.createSocket(DashoA6275:line unknown, pc 0x819f3c5) at SSLSocketClient.main(SSLSocketClient.java:41) -- -- -- I've got that far as well. I think that the error is occured when the program initializes keystore. From sun java site, the error, SSL implementation not available, can be occured when there was a problem with SSLContext initialization, for example due to a corrupted keystore. (Note: One vendor has shipped a keystore in an unknown format, and that may cause this type of error.) And the solusion is Check initialization parameters. Ensure any keystores specified are valid (e.g., by trying to use the keytool to examine them). Sun's JSSE documentation is not very helpful in that respect. But then, their JSSE has never been supposed to be run on other VMs anyway, I assume. One needs Sun's own provider in order to be able to provide an algorithm to read keystores in the default, proprietary format, JKS. The algorithm is in Sun's JDK's rt.jar. I've tried adding sun's rt.jar from jdk 1.3 to kaffe's bootclasspath, as well as setting security providers to sun's providers only, and added the j*.jar files from the jsse distribution to kaffe's bootclasspath. Then I got much further: bash-2.05a$ kaffe -Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol -cp ../../lib/jnet.jar:../../lib/jsse.jar:../../lib/jcert.jar -Djavax.net.debug=all URLReader [snip] verify exception was: java.lang.ClassCastException: can't cast `com/sun/net/ssl/internal/ssl/JSA_SHA1RSASignature' to `java/security/Signature' main, SEND SSL v3.0 ALERT: fatal, description = certificate_unknown main, WRITE: SSL v3.0 Alert, length = 2 javax.net.ssl.SSLException: untrusted server cert chain at java.lang.Throwable.fillInStackTrace(Throwable.java:native) at java.lang.Throwable.init(Throwable.java:44) at java.lang.Exception.init(Exception.java:24) at java.io.IOException.init(IOException.java:24) at javax.net.ssl.SSLException.init(DashoA6275:line unknown, pc 0x86d8ba6) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275:line unknown, pc 0x868c1ad) at com.sun.net.ssl.internal.ssl.ClientHandshaker.a(DashoA6275:line unknown, pc 0x86c9c17) at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(DashoA6275:line unknown, pc 0x84844ef) at com.sun.net.ssl.internal.ssl.Handshaker.process_record(DashoA6275:line unknown, pc 0x82fd5ca) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275:line unknown, pc 0x84a1855) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275:line unknown, pc 0x845c394) at com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA6275:line unknown, pc 0x845eef8) at java.io.OutputStream.write(OutputStream.java:24) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(DashoA6275:line unknown, pc 0x832bcf3) at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.doConnect(DashoA6275 :line unknown, pc 0x84195de) at com.sun.net.ssl.internal.www.protocol.https.NetworkClient.openServer(DashoA6 275:line unknown, pc 0x83b1468) at com.sun.net.ssl.internal.www.protocol.https.HttpClient.l(DashoA6275:line unknown, pc 0x83eba76) at com.sun.net.ssl.internal.www.protocol.https.HttpClient.init(DashoA6275:lin e unknown, pc 0x8402427) at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.init(DashoA6275:li ne unknown, pc 0x839ec02) at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.a(DashoA6275:line unknown, pc 0x83f18bd) at
Release freeze tomorrow? (Was: Re: [kaffe] Re: Makefile for java.nio)
Salut Daniel, --- Daniel Bonniot [EMAIL PROTECTED] wrote: I haven't tried it with jikes yet, but I've just checked in a fix that worked for me on kjc. Thanks, it works with jikes too. So I can now report that kaffe built correctly, and make check reports no error (only TestNative.java was SKIP'ed, is that normal?). it's skipped, unless you build kaffe with --enable-debug. Furthermore, it could by used to bootstrap my Nice compiler (http://nice.sf.net). So as far as I am concerned, kaffe 1.1 can be released ;-) that's some good news. ;) What are the plans when approaching the release (still on June 1st?). Will there be a release candidate? A CVS freeze, so people can do a last test? Here's my list of things that remain to be done: * check reported build problems with qt (me) * fix KAFFE_DEBUG_TEMPFILE security problems using mktemp (me) * check in QPE fixes from jim huang (me) * check in fix for libtool.m4 for m68k-amiga from tony (me) * fix whatever problems remain with make dist and make distcheck * update FAQ.autoconf to recommend latest versions of the tools * update FAQ.unicode to reflect that kaffe uses Classpath's implementation now * look into the latest freenet crash traces If anyone could write a few manpages for kaffe tools other than kaffe (and update kaffe.1 to reflect the current state of affairs, like the options added in the last 3 years ;), that would be great, too. If we could get most of that done today, freeze tomorrow and create a rc1 tarball, and release until the weekend, I'd be very impressed ;) Jim, do you have time to organize the release? Cheers, Daniel PS: Dalibor, I saw in CVS that you wrote FAQ.mauve, thanks. It did not appear yet on the web site, though. Thanks for the reminder, I'll put it on the web. ;) cheers, dalibor topic __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] build failure if old version present, ServletContext.setAttribute
On Tue, 27 May 2003 18:50:40 -0400 Greg Wooledge [EMAIL PROTECTED] wrote: 26-May-03 7:21:43 PM (freenet.interfaces.LocalInterface, Interface # tcp/, ERROR): Unhandled throw accepting connections: Interface # tcp/ java.lang.NullPointerException at freenet.transport.tcpConnection.init(tcpConnection.java:123) at freenet.transport.tcpListener.accept(tcpListener.java:48) at freenet.interfaces.Interface.acceptConnections(Interface.java:214) at freenet.interfaces.Interface.run(Interface.java:169) should be fixed by now, so I'm waiting for the next one ;) Ask and ye shall receive Seems like we're moving on to the more interesting stuff ;) From the traces you've sent in this thread, I would assume that this assertion failure only occurrs when you get a NullPointerException, is that correct? The past two times, that seemed to be the case. However, it's different today, as shown below. There are actually two different assertions that fail: * The !INTS_DISABLED one somewhere in exception.c which seems to fail only after a NullPointerException. If that is correct, I would suspect that kaffe's signal handling doesn't work 100% correct on OpenBSD and This one occurs after clicking a few things on the web interface, less than a minute after the node has finished initializing. There is no accompanying message in freenet.log, and stdout/stderr has only this: assertion blk-free != 0 failed: file mem/gc-mem.c, line 324 * this one, which fails because some of kaffe's data structures needed fo heap management get corrupted (due to some race condition between heap_malloc and heap_free). Will look into this one, but if I cannot come up with a simple patch, I will not fix it till after the release, since I won't make any big changes to the garbage collector at this point Greetings, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] build failure if old version present, ServletContext.setAttribute
From the traces you've sent in this thread, I would assume that this assertion failure only occurrs when you get a NullPointerException, is that correct? The past two times, that seemed to be the case. However, it's different today, as shown below. There are actually two different assertions that fail: * The !INTS_DISABLED one somewhere in exception.c which seems to fail only after a NullPointerException. If that is correct, I would suspect that kaffe's signal handling doesn't work 100% correct on OpenBSD One sees (or used to see) the same failure mode under Linux if the stack frame or (more often) the frame pointer register is corrupted. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Kaffe CVS: kaffe dalibor
CVSROOT:/cvs/kaffe Module name:kaffe Changes by: dalibor 03/05/29 04:41:57 Modified files: . : ChangeLog libraries/javalib: Makefile.in Log message: 2003-05-29 Dalibor Topic [EMAIL PROTECTED] * libraries/javalib/Makefile.in: regenerated. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] build failure if old version present, ServletContext.setAttribute
On Thu, 29 May 2003 13:42:07 +0200 Kevin D. Kissell [EMAIL PROTECTED] wrote: From the traces you've sent in this thread, I would assume that this assertion failure only occurrs when you get a NullPointerException, is that correct? The past two times, that seemed to be the case. However, it's different today, as shown below. There are actually two different assertions that fail: * The !INTS_DISABLED one somewhere in exception.c which seems to fail only after a NullPointerException. If that is correct, I would suspect that kaffe's signal handling doesn't work 100% correct on OpenBSD One sees (or used to see) the same failure mode under Linux if the stack frame or (more often) the frame pointer register is corrupted. With both, mips and i386? ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
