Re: array overflow in local.c
On Jun 27, 2008, at 6:15 AM, Robert Schuster wrote: Hi. Andrew Haley schrieb: Furthermore since overrunning the bounds of a stack allocated array may trash other stuff on the stack I wonder whether this fix also prevents the problem that the workaround above the modified code speaks of. Since I do not run Darwin-based OS I cannot test it myself. That may well be right. IMO it should be more like OK. Casey would you mind testing the attached patch on your Darwin platform? I'll give it a try when I get a chance, but this patch looks fine as is. (And I'm embarrassed; `addr' was being set to NULL, if I remember correctly)
Re: [GNU Crypto] bug report wrt EMSA_PSS.java: the private method *byte[] MGF(byte[] Z, int l)* does not produce a complete mask...
I'm forwarding this to the GNU Classpath list. We're maintaining GNU
Crypto as a part of GNU Classpath now, and in the near term there are
no plans for a new release of GNU Crypto.
The bug report may still be valid for GNU Classpath though. Do you
have a test case that we can use?
On Mon, May 5, 2008 at 1:30 AM, Danny De Cock [EMAIL PROTECTED] wrote:
hi,
I just discovered a bug in the class file EMSA_PSS.java: the mask
generation function MGF does not work correctly: the last masking block
does not get filled properly...
this is due to the fact that the loop for(int i=0;ilimit;i++){step 3.1
step 3.2} stops one iteration too early, which results in trailing zeroes
in the result variable...
the problem can easily be solved: for(int i=0;i=limit;i++){step 3.1
step 3.2} does the trick...
I discovered this thanks to an interoperability test... an rsa/pss
signature did not verify correctly with
gnu.java.security.sig.rsa.RSAPSSSignature.java
kind regards, danny.
-
of course I am ignorant. I just worry whether or not I am ignorant enough...
-
mail: danny.decock:at:esat:dot:kuleuven:dot:behttp://godot.be
godot:at:advalvas:dot:be http://godot.studentenweb.org
godot:at:godot:dot:be web: http://www.esat.kuleuven.be/~decockd
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
___
gnu-crypto-discuss mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/gnu-crypto-discuss
Re: [jade-develop] NotYetConnectedException
On Oct 1, 2007, at 10:10 AM, Robert Dodier wrote: Hello, A little bit more information. I've quoted a previous message below to provide context. I hope that someone who is familiar with the Classpath NIO code can at least suggest some avenue for further debugging. I rewrote a great deal of it; if you've found a bug, it may be my fault. After equipping VMChannel.java and SocketChannelImpl.java with some debug output, I see the following. This occurs after running for several hours. [...] The immediate problem is that the instance variable VMChannel.State.valid is false when VMChannel.write is called. Either it was never true, or it was true and then changed to false. Reading through VMChannel.java and its associated native code, gnu_java_nio_VMChannel.c, I don't see how valid is maintained. The 'valid' flag of VMChannel.State *should* only become true when it is initialized with a valid native file descriptor; it should then only become false when the underlying file descriptor is closed. You might want to instrument the 'close' method of VMChannel.State, and see if it is getting called at an unexpected time. Having a look at VMChannel again, I see that operations on State aren't thread-safe. This might be the problem. Also our NIO may just not be emulating the Sun version properly, and there's a method that you can call on a closed channel that we aren't allowing. It would be very helpful if you can come up with a simple test case. Thanks.
[cp-patches] Re: Ping: Fix DiffieHellmanImpl.java
Sorry I forgot about this. On Sep 4, 2007, at 11:17 AM, Andrew Haley wrote: From: Andrew Haley [EMAIL PROTECTED] Date: August 3, 2007 10:19:07 AM PDT To: Casey Marshall [EMAIL PROTECTED], classpath-patches@gnu.org Cc: Lillian Angel [EMAIL PROTECTED] Subject: Fix DiffieHellmanImpl.java I came across a problem with GNU Crypto that causes Diffie-Hellman key exchange to fail when running on IcedTea. We're doing what looks to me like an unnecessary check in DiffieHellmanImpl.engineDoPhase() which can fail in some circumstances, and this is triggered when running in IcedTea. The code runs correctly on Sun's Java 1.7, not on the IcedTea version of Java 1.7, which uses GNU Crypto. I think this is OK. I'm sure there are valid instances where the l values won't match. With IcedTea and Classpath we get: Exception in thread main java.security.InvalidKeyException: Incompatible key at gnu.javax.crypto.jce.DiffieHellmanImpl.engineDoPhase (DiffieHellmanImpl.java:99) at javax.crypto.KeyAgreement.doPhase(KeyAgreement.java:224) at Tt.main(Tt.java:35) Here's my patch:
Re: PBEWithMD5AndDES Implementation
On Jul 16, 2007, at Jul 16, 3:31 PM, Lillian Angel wrote: Hi, I am currently working on IcedTea and trying to get the testcase attached to the bug report [1] working. I need to implement the PBEWithMD5AndDES algorithm. I am wondering if anyone can point me in the right direction? I do not have much experience with crypto. This is not implemented in Classpath either, so it will be worth implementing. I'm pretty sure that PBEwithMD5andDES in the JDK's parlance refers to RSA's password-based encryption spec, PKCS #5, version 1.5 [1]. The MD5 refers to the MD5 MessageDigest, and the DES the DES Cipher. The way to go here is to write a generic PBE implementation, and subclass it for each hash and cipher combination in Classpath. This shouldn't be too difficult, since the MessageDigest and Cipher bits are already implemented. Classpath implements a later (alas, incompatible) version of this spec, in gnu.javax.crypto.jce.cipher.PBES2. 1. ftp://ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-5.asc
Re: [cp-patches] Re: RFC: native/jni/java-nio/gnu_java_nio_VMChannel.c
On Jun 27, 2007, at 3:27 PM, Ito Kazumitsu wrote: Casey Marshall wrote. I meant the curly braces, the #if..#endif is appropriate. The source code now looks like this. What is the preferred way of writing this? Sorry, I'm just stupid :-) I read the patch wrong; it's good as-is. Thanks.
Re: [cp-patches] RFC: native/jni/java-nio/gnu_java_nio_VMChannel.c
On Jun 20, 2007, at 3:32 PM, Ito Kazumitsu wrote:
Hi,
Hi Ito,
FreeBSD needs both ioctl and fstat, The former for character devices
and the latter for files.
This looks fine to me; I admit I haven't tried it, but nothing
obviously wrong jumps out at me.
Thanks.
ChangeLog:
2007-06-21 Ito Kazumitsu [EMAIL PROTECTED]
Fixes bug #30377
* native/jni/java-nio/gnu_java_nio_VMChannel.c
(Java_gnu_java_nio_VMChannel_available): Retry using fstat if ioctl
fails with ENOTTY.
Index: classpath/native/jni/java-nio/gnu_java_nio_VMChannel.c
===
RCS file: /cvsroot/classpath/classpath/native/jni/java-nio/
gnu_java_nio_VMChannel.c,v
retrieving revision 1.19
diff -u -r1.19 gnu_java_nio_VMChannel.c
--- classpath/native/jni/java-nio/gnu_java_nio_VMChannel.c 30 May
2007 09:56:57 - 1.19
+++ classpath/native/jni/java-nio/gnu_java_nio_VMChannel.c 20 Jun
2007 22:22:14 -
@@ -1586,9 +1586,30 @@
jint avail = 0;
+#if defined(ENOTTY) defined(HAVE_FSTAT)
+ struct stat statBuffer;
+ off_t n;
+#endif
+
/* NIODBG(fd: %d, fd); */
if (ioctl (fd, FIONREAD, avail) == -1)
-JCL_ThrowException (env, IO_EXCEPTION, strerror (errno));
+{
Not sure why you have this block...
+#if defined(ENOTTY) defined(HAVE_FSTAT)
+ if (errno == ENOTTY)
+{
+ if ((fstat (fd, statBuffer) == 0) S_ISREG
(statBuffer.st_mode))
+{
+ n = lseek (fd, 0, SEEK_CUR);
+ if (n != -1)
+{
+ avail = statBuffer.st_size - n;
+ return avail;
+}
+}
+}
+#endif
+ JCL_ThrowException (env, IO_EXCEPTION, strerror (errno));
...surrounding it, though.
+}
/* NIODBG(avail: %d, avail); */
return avail;
Re: [cp-patches] FYI Only truncate a file on append and write-only (from FileOutputStream)
On May 30, 2007, at 4:21 AM, Steve Blackburn wrote: Is there any particular reason for having native implementations of open() in both gnu_java_nio_VMChannel.c and gnu_java_nio_FileChannelImpl.c? Aside from the bug in VMChannel, this duplication of open seemed to be the cause of the problem I saw. gnu_java_nio_FileChannelImpl.c was removed from CVS, six months ago. Refactoring of FileChannelImpl.java lead to an (unintended?) switch between open() implementations and exposed the bug. I couldn't work out why there were two implementations in the first place. The point of the refactoring was to move all of the native methods from FileChannelImpl into the the VM/platform layer, VMChannel. It was completely deliberate to switch to VMChannel -- that was the point. As for the bug, oops (I think it may have been my fault).
Re: [cp-patches] Gnu classpath permission patch ?
On May 25, 2007, at 12:37 AM, Pierre Parrend wrote:
Hello,
thanks for the tip, to tell the Classes to use the right policy
reader is usefull. However, I now get a ugly NullPointerException
in policy reading, it seems that the given reader has problem
reading the name of the ProtectionDomain:
Hmm, no, this looks more like a problem with recursive permission
checks; that is, something needs to have a permission checked while
it's checking a permission. It also looks like Classpath will
eventually deny the permission your code is requesting.
This is a little odd, because it looks like Classpath internal code
is being denied a permission. That's wrong; library code should be
able to do what it pleases.
This feels like a regression. What version of Classpath and jamvm are
you using?
Thanks.
java.lang.ExceptionInInitializerError
at gnu.java.security.x509.X509Certificate.toString
(X509Certificate.java:455)
at java.lang.StringBuffer.append(StringBuffer.java:348)
at java.security.CodeSource.toString(CodeSource.java:269)
at java.lang.StringBuffer.append(StringBuffer.java:348)
at java.security.ProtectionDomain.toString(ProtectionDomain.java:
212)
at java.lang.StringBuffer.append(StringBuffer.java:348)
at java.security.AccessControlContext.checkPermission
(AccessControlContext.java:157)
at java.security.AccessController.checkPermission
(AccessController.java:76)
at java.lang.SecurityManager.checkPermission
(SecurityManager.java:356)
at java.lang.SecurityManager.checkPropertyAccess
(SecurityManager.java:820)
at java.lang.System.getProperty(System.java:397)
at org.apache.felix.main.Main.clinit(Main.java:66)
Caused by: java.lang.NullPointerException
at java.io.PrintWriter.println(PrintWriter.java:395)
at java.io.PrintWriter.println(PrintWriter.java:523)
at gnu.java.security.x509.X509Certificate.toString
(X509Certificate.java:456)
at java.lang.StringBuffer.append(StringBuffer.java:348)
at java.security.CodeSource.toString(CodeSource.java:269)
at java.lang.StringBuffer.append(StringBuffer.java:348)
at java.security.ProtectionDomain.toString(ProtectionDomain.java:
212)
at java.lang.StringBuffer.append(StringBuffer.java:348)
at java.security.AccessControlContext.checkPermission
(AccessControlContext.java:157)
at java.security.AccessController.checkPermission
(AccessController.java:76)
at java.lang.SecurityManager.checkPermission
(SecurityManager.java:356)
at java.lang.SecurityManager.checkPropertyAccess
(SecurityManager.java:820)
at java.lang.System.getProperty(System.java:418)
at java.io.PrintWriter.clinit(PrintWriter.java:381)
at gnu.java.security.x509.X509Certificate.toString
(X509Certificate.java:455)
Quoting Casey Marshall [EMAIL PROTECTED]:
On May 24, 2007, at 1:58 PM, Pierre Parrend wrote:
Hello,
for instance, I have the following command:
jamvm -Djava.security.manager -Djava.security.policy=conf/
java.policy -cp
bin/felix.jar: org.apache.felix.main.Main
(jamvm uses the Gnu classpath, with default configuration)
with following conf/java.policy file:
grant codeBase /code/osgi-projects/sfelix/sfelix0.2.2/main/- {
permission java.io.FilePermission /home/pierre/.felix/
testSF, read;
permission java.lang.RuntimePermission exitVM;
};
which gives me following error:
Error creating bundle cache:
permission (java.io.FilePermission /home/pierre/.felix/testSF
read) not granted:
no protection domains
Could not create framework: java.security.AccessControlException:
permission
(java.lang.RuntimePermission exitVM ) not granted: no protection
domains
java.security.AccessControlException: permission
(java.lang.RuntimePermission
exitVM ) not granted: no protection domains
at
java.security.AccessControlContext.checkPermission
(AccessControlContext.java:149)
at java.security.AccessController.checkPermission
(AccessController.java:76)
at java.lang.SecurityManager.checkPermission
(SecurityManager.java:356)
at java.lang.SecurityManager.checkExit(SecurityManager.java:475)
at java.lang.Runtime.exit(Runtime.java:171)
at java.lang.System.exit(System.java:506)
at
org.apache.felix.framework.util.SecureAction$Actions.run
(SecureAction.java:843)
at java.security.AccessController.doPrivileged
(AccessController.java:195)
at org.apache.felix.framework.util.SecureAction.exit
(SecureAction.java:624)
at org.apache.felix.framework.Felix.start(Felix.java:276)
at org.apache.felix.main.Main.main(Main.java:208)
(executed platform is the Felix OSGi implementation, which work
well without the
security set)
One problem here is that Classpath still unfortunately uses a bogus
DefaultPolicy class for its policy, not the one that reads policy
files. You can force using the policy file reader by adding the
option:
-Dpolicy.provider=gnu.java.security.PolicyFile
...I don't know why the default policy would reject the permission
checks
Re: [cp-patches] Gnu classpath permission patch ?
On May 24, 2007, at 11:03 AM, Pierre Parrend wrote: Hello, in a different test context, it works. But I do not manage to get the java.policy file read, so my code aborts very soon. Does someone knows whether the supported syntax of this file is identical as in the sun jvm ? It seems that jamvm+Gnu Classpath has some difficulties in reading the properties that are defined (such a - Djava.security.policy). Any idea ? We do have a Policy implementation that reads Sun-style policy files, but we don't know if it is 100% compatible. If there is something we don't correctly support, I'd encourage you to file a bug report. We can't offer any more help unless you can be more specific about what error you are running into.
Re: [cp-patches] Gnu classpath permission patch ?
On May 24, 2007, at 1:58 PM, Pierre Parrend wrote:
Hello,
for instance, I have the following command:
jamvm -Djava.security.manager -Djava.security.policy=conf/
java.policy -cp
bin/felix.jar: org.apache.felix.main.Main
(jamvm uses the Gnu classpath, with default configuration)
with following conf/java.policy file:
grant codeBase /code/osgi-projects/sfelix/sfelix0.2.2/main/- {
permission java.io.FilePermission /home/pierre/.felix/
testSF, read;
permission java.lang.RuntimePermission exitVM;
};
which gives me following error:
Error creating bundle cache:
permission (java.io.FilePermission /home/pierre/.felix/testSF read)
not granted:
no protection domains
Could not create framework: java.security.AccessControlException:
permission
(java.lang.RuntimePermission exitVM ) not granted: no protection
domains
java.security.AccessControlException: permission
(java.lang.RuntimePermission
exitVM ) not granted: no protection domains
at
java.security.AccessControlContext.checkPermission
(AccessControlContext.java:149)
at java.security.AccessController.checkPermission
(AccessController.java:76)
at java.lang.SecurityManager.checkPermission
(SecurityManager.java:356)
at java.lang.SecurityManager.checkExit(SecurityManager.java:475)
at java.lang.Runtime.exit(Runtime.java:171)
at java.lang.System.exit(System.java:506)
at
org.apache.felix.framework.util.SecureAction$Actions.run
(SecureAction.java:843)
at java.security.AccessController.doPrivileged
(AccessController.java:195)
at org.apache.felix.framework.util.SecureAction.exit
(SecureAction.java:624)
at org.apache.felix.framework.Felix.start(Felix.java:276)
at org.apache.felix.main.Main.main(Main.java:208)
(executed platform is the Felix OSGi implementation, which work
well without the
security set)
One problem here is that Classpath still unfortunately uses a bogus
DefaultPolicy class for its policy, not the one that reads policy
files. You can force using the policy file reader by adding the option:
-Dpolicy.provider=gnu.java.security.PolicyFile
...I don't know why the default policy would reject the permission
checks, though, since (AFAIK) the default policy grants AllPermission.
Re: 0.95 branch created
On Apr 6, 2007, at 3:51 PM, Mark Wielaard wrote: Mauve regressions that should be fixed/investigated: FAIL: gnu.java.security.jce.TestOfHttps FAIL: java.net.URLConnection.getHeaderFields (Seems to have to do something with how we handle the cacerts file) Undoubtedly, yes. The best way to fix this is likely going to be just creating a TrustManager for Mauve that only returns whatever cert the test server it connects to is using, instead of trying to mess around with a real cacerts file. Thanks.
[cp-patches] FYI: fix keyUsage bit checking
Our SSL client implementation was just passing the certificate to the RSA cipher, in the RSA key exchange. This implicitly checks the `dataEncipherment' bit of the certificate's keyUsage field, which isn't correct. The correct test is for the `keyEncipherment' bit. 2007-03-22 Casey Marshall [EMAIL PROTECTED] * gnu/javax/net/ssl/provider/ClientHandshake.java (RSAGen.implRun): check keyEncipherment bit of the certificate, and just pass the public key to the cipher. Committed. ssl-keyusage.patch Description: Binary data
[commit-cp] classpath ChangeLog gnu/javax/net/ssl/provider/...
CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Casey Marshall rsdio 07/03/23 04:53:59 Modified files: . : ChangeLog gnu/javax/net/ssl/provider: ClientHandshake.java Log message: 2007-03-22 Casey Marshall [EMAIL PROTECTED] * gnu/javax/net/ssl/provider/ClientHandshake.java (RSAGen.implRun): check keyEncipherment bit of the certificate, and just pass the public key to the cipher. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9165r2=1.9166 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/javax/net/ssl/provider/ClientHandshake.java?cvsroot=classpathr1=1.2r2=1.3
[cp-patches] RFC: exceptions with no string constructor
I'm still testing this. This patch adds a JCL_ThrowExceptionNoMessage function, which invokes the void constructor of the given class, There are also a couple of issues in general in jcl.c. One is that in JCL_ThrowException, we throw a ClassNotFoundException if the specified exception class can't be found. There are two issues: 1. We don't return after throwing that exception, meaning we'll continue on and call ThrowNew again with a NULL class argument. 2. ClassNotFoundException is a checked exception, but very likely the native method we are in does not declare that it throws this. Could this be trouble brewing? Also, in JCL_malloc and JCL_realloc we throw OutOfMemoryExceptions if the native calls return NULL. It doesn't seem like this will work (though, if there is an explanation of why it will always work, I'll listen), so I've also modified this to allocate a static OutOfMemoryException on load, and these methods now throw that instance. 2007-02-02 Casey Marshall [EMAIL PROTECTED] * native/jni/classpath/jcl.c (OOM_obj): new static variable. (JNI_OnLoad): initialize `OOM_obj'. (JCL_ThrowException): return after throwing class not found exception. (JCL_ThrowExceptionNoMessage): new function. (JCL_malloc, JCL_realloc): throw `OOM_obj'. * native/jni/classpath/jni.h: include assert.h. (JCL_ThrowExceptionNoMessage): new function. * native/jni/java-nio/gnu_java_nio_VMChannel.c (Java_gnu_java_nio_VMChannel_read__ILjava_nio_ByteBuffer_2): don't throw NonReadableChannelException with a message. (Java_gnu_java_nio_VMChannel_readScattering): likewise. (Java_gnu_java_nio_VMChannel_writeGathering): don't throw NonWritableChannelException with a message. jcl-excep.patch Description: Binary data
Re: [cp-patches] RFC: exceptions with no string constructor
On Feb 2, 2007, at 9:55 PM, Jeroen Frijters wrote: Casey Marshall wrote: Also, in JCL_malloc and JCL_realloc we throw OutOfMemoryExceptions if the native calls return NULL. It doesn't seem like this will work (though, if there is an explanation of why it will always work, I'll listen), so I've also modified this to allocate a static OutOfMemoryException on load, and these methods now throw that instance. That's a good idea, but there's a bug in the implementation: +(*env)-NewGlobalRef (env, OOM_obj); That's not how NewGlobalRef works, it returns a new global ref, it doesn't modify the passed in ref. Yes indeed! Thanks for mentioning this.
Re: exception bug in gnu_java_nio_VMChannel.c
On Feb 2, 2007, at 1:07 AM, Christian Thalinger wrote: On Thu, 2007-02-01 at 17:16 -0800, Casey Marshall wrote: On Feb 1, 2007, at 3:39 PM, Christian Thalinger wrote: Hi! I found a problem in gnu_java_nio_VMChannel.c. It's about NonReadableChannelException and NonWriteableChannelException. These exceptions do not have a initializer with String as parameter: java.lang.NoSuchMethodError: java.nio.channels.NonReadableChannelException.init(Ljava/lang/ String;)V at gnu.java.nio.VMChannel.read(Native Method) at gnu.java.nio.VMChannel.read(VMChannel.java:159) But the C code assumes this, like: JCL_ThrowException (env, NON_READABLE_CHANNEL_EXCEPTION, strerror (errno)); I don't know exactly how to fix this properly. The C code should just throw a new exception without trying to pass in a message string. This would mean no longer using JCL_ThrowException, and doing a NewObject/ThrowException manually, but whatever. We could introduce a JCL function that throws an exception with no message string. I think that would be the best idea. Have you time to do that? A little ;-) I'll look into this.
Re: exception bug in gnu_java_nio_VMChannel.c
On Feb 1, 2007, at 3:39 PM, Christian Thalinger wrote: Hi! I found a problem in gnu_java_nio_VMChannel.c. It's about NonReadableChannelException and NonWriteableChannelException. These exceptions do not have a initializer with String as parameter: java.lang.NoSuchMethodError: java.nio.channels.NonReadableChannelException.init(Ljava/lang/ String;)V at gnu.java.nio.VMChannel.read(Native Method) at gnu.java.nio.VMChannel.read(VMChannel.java:159) But the C code assumes this, like: JCL_ThrowException (env, NON_READABLE_CHANNEL_EXCEPTION, strerror (errno)); I don't know exactly how to fix this properly. The C code should just throw a new exception without trying to pass in a message string. This would mean no longer using JCL_ThrowException, and doing a NewObject/ThrowException manually, but whatever. We could introduce a JCL function that throws an exception with no message string.
[cp-patches] FYI: CipherOutputStream null check
I'm checking this in. It uses the suggested fix for Cipher implementations that may return `null', at the end of PR 24191. 2007-01-31 Casey Marshall [EMAIL PROTECTED] Fixes PR classpath/24191. Fix suggested by Rafael Teixeira [EMAIL PROTECTED]. * javax/crypto/CipherOutputStream.java (write): check return value of `update' for null. Cheers. coos.patch Description: Binary data
[cp-patches] FYI: consolidate Base-64 implementations
I'm checking this in. This removes two of the four Base-64 classes we have in Classpath (the last one is stream-based, so I'm not going to muck with it just yet) and updates the code to use the one implementation everywhere. I'm using the version that I wrote (since I volunteered to do this, I assumed veto power over which version to use ;-), which was in gnu.javax.net.ssl. I've moved that class to gnu.java.util.Base64, so if you have Base-64 encoding needs, use that one from now on! 2007-01-31 Casey Marshall [EMAIL PROTECTED] * gnu/javax/net/ssl/Base64.java: move to `gnu/java/util/Base64.java.' * gnu/javax/net/ssl/PrivateCredentials.java: clean up unused imports. (add): use `gnu.java.util.Base64.' * gnu/java/net/protocol/http/Request.java (authenticate): use `gnu.java.util.Base64.' * tools/gnu/classpath/tools/jarsigner/HashUtils.java (hashStream): likewise. * tools/gnu/classpath/tools/keytool/CertReqCmd.java (start): likewise. * tools/gnu/classpath/tools/keytool/ExportCmd.java (start): likewise. * tools/gnu/classpath/tools/keytool/ListCmd.java (printRFC1421): likewise. * gnu/java/net/Base64.java: removed. * gnu/java/security/util/Base64.java: removed. Cheers. base64.patch Description: Binary data
[commit-cp] classpath javax/crypto/CipherOutputStream.java ...
CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Casey Marshall rsdio 07/02/01 01:24:20 Modified files: javax/crypto : CipherOutputStream.java . : ChangeLog Log message: 2007-01-31 Casey Marshall [EMAIL PROTECTED] Fixes PR classpath/24191. Fix suggested by Rafael Teixeira [EMAIL PROTECTED]. * javax/crypto/CipherOutputStream.java (write): check return value of `update' for null. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/javax/crypto/CipherOutputStream.java?cvsroot=classpathr1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9080r2=1.9081
[commit-cp] classpath gnu/javax/net/ssl/PrivateCredentials....
CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Casey Marshall rsdio 07/02/01 03:45:00 Modified files: gnu/javax/net/ssl: PrivateCredentials.java gnu/java/net/protocol/http: Request.java tools/gnu/classpath/tools/jarsigner: HashUtils.java . : ChangeLog tools/gnu/classpath/tools/keytool: ListCmd.java ExportCmd.java CertReqCmd.java Added files: gnu/java/util : Base64.java Removed files: gnu/javax/net/ssl: Base64.java gnu/java/security/util: Base64.java gnu/java/net : BASE64.java Log message: 2007-01-31 Casey Marshall [EMAIL PROTECTED] * gnu/javax/net/ssl/Base64.java: move to `gnu/java/util/Base64.java.' * gnu/javax/net/ssl/PrivateCredentials.java: clean up unused imports. (add): use `gnu.java.util.Base64.' * gnu/java/net/protocol/http/Request.java (authenticate): use `gnu.java.util.Base64.' * tools/gnu/classpath/tools/jarsigner/HashUtils.java (hashStream): likewise. * tools/gnu/classpath/tools/keytool/CertReqCmd.java (start): likewise. * tools/gnu/classpath/tools/keytool/ExportCmd.java (start): likewise. * tools/gnu/classpath/tools/keytool/ListCmd.java (printRFC1421): likewise. * gnu/java/net/Base64.java: removed. * gnu/java/security/util/Base64.java: removed. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/javax/net/ssl/PrivateCredentials.java?cvsroot=classpathr1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/javax/net/ssl/Base64.java?cvsroot=classpathr1=1.1r2=0 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/util/Base64.java?cvsroot=classpathrev=1.1 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/net/protocol/http/Request.java?cvsroot=classpathr1=1.12r2=1.13 http://cvs.savannah.gnu.org/viewcvs/classpath/tools/gnu/classpath/tools/jarsigner/HashUtils.java?cvsroot=classpathr1=1.5r2=1.6 http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9081r2=1.9082 http://cvs.savannah.gnu.org/viewcvs/classpath/tools/gnu/classpath/tools/keytool/ListCmd.java?cvsroot=classpathr1=1.6r2=1.7 http://cvs.savannah.gnu.org/viewcvs/classpath/tools/gnu/classpath/tools/keytool/ExportCmd.java?cvsroot=classpathr1=1.7r2=1.8 http://cvs.savannah.gnu.org/viewcvs/classpath/tools/gnu/classpath/tools/keytool/CertReqCmd.java?cvsroot=classpathr1=1.6r2=1.7 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/security/util/Base64.java?cvsroot=classpathr1=1.4r2=0 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/net/BASE64.java?cvsroot=classpathr1=1.3r2=0
Re: VMChannel read/write native interface
On Jan 28, 2007, at 12:15 AM, Robin Garner wrote: I've been looking into why JikesRVM sucks so badly on the DaCapo xalan benchmark (it's approx 20x slower than the commercial JVMs). One of the characteristics of this benchmark (at least in its current incarnation) is that it does a very large number of 1- and 2-byte file write operations. JikesRVM currently uses the default reference VMChannel implementation, which crosses the Java-native boundary with the call static native int read(int fd, ByteBuffer buf); The C implementation then uses JNI to invoke methods on the ByteBuffer to get its length and I/O start position, obtain a pointer to the backing array, release the array and write the new position back to the buffer. Allocating a direct buffer for buf, and adding the interface method static native int read(int fd, ByteBuffer buf, int len, int pos); and writing the buffer position back in Java halves the execution time of the benchmark. (the 'write' method is implemented identically) Is there much difference in using the same buffer (not necessarily direct) but passing in the `len' and `pos' values in Java? If a lot of the slowdown is caused by the JNI calls to figure these values out, then adding those parameters to the interface method (which IIRC is private anyway, and not a part of the Java VM layer) then we should do that. I guess what's left is getting the buffer's backing array, which is another few JNI calls. That can be optimized on a VM-by-VM basis, but may be harder to abstract into an interface. If we split the `JCL_buffer' stuff in the VMChannel code into its own library, VM implementors could provide their own version of that library, optimized for that VM. This still leaves the issue of arranging for buf to be a direct byte buffer.In my current patch I've modified FileInputStream.java to arrange for a direct buffer to be used, but this doesn't seem very satisfactory. What I would like to do is intercept the ByteBuffer.wrap method and do 'the optimal thing', eg use the user's buffer as a DirectBuffer if it is in a non-moving space, or something less optimal otherwise, and back this up with a static analysis that allocates I/O buffers in a non-moving space if it can. We could add a new VM method (in VMChannels or something) that does the job of wrap -- and set the reference implementation to the one we have now. There's stuff I can do in JikesRVM to speed up the native calls, eliminate some of the buffer copies etc but the further back in the call chain I do it (ie in this code) the more scope there is for optimization. So my questions to the list are: - If I was to contribute the above reimplementation of read and write, would it be accepted ? Or should I pursue a JikesRVM-specific approach ? In general I like the approach of keeping the JNI calls in native code as few as possible, so I think this would be fine. - What is the best way to put a VM-specific hook into ByteBuffer.wrap ? Is there an existing facility I've missed ? Like I said above, we'd add a method 'wrap' to some VM class, then change ByteBuffer.wrap so it just calls the same method of the VM class. Maybe adding a new VM class 'java.nio.VMBuffers' would be appropriate. Of course adding a BufferedWriter also solves the performance problem for xalan, but the commercial class libraries seem to have optimized this call (adding the buffer results in no measurable speedup in the sun JDK), so I think we can expect unoptimized user code to become more widespread, and there is probably a (albeit probably less dramatic) payoff for other code. Another approach would be to just make File*putStream do their own buffering, though I suppose that approach may have drawbacks in some situations. Thanks.
Re: Classpath Tools and JamVM with --disable-zip
On Jan 28, 2007, at 1:13 PM, Alexander Gromnizki wrote: Hi, Prologue: I'm very new to Java. After compiling and installing on FreeBSD 6.0 Classpath 0.93 (--with-jikes --disable-gtk-peer --disable-gconf-peer --disable-plugin --enable-local-sockets --enable-xmlj --prefix=/opt/java) and JamVM 1.4.4 (--prefix=/opt/java --with-classpath-install-dir=/opt/java --disable-zip) I did: # pwd /opt/java/share/classpath # unzip glibj.zip # unzip tools.zip # rm glibj.zip tools.zip And my HelloWorld test runs fine. But when I'm trying to execute any Classpath tool (for example, gjar) I'm getting: % jamvm gnu.classpath.tools.jar.Main [...] Caused by: java.io.IOException: Inappropriate ioctl for device at gnu.java.nio.VMChannel.available(Native Method) That method does this in Classpath: jint avail = 0; if (ioctl (fd, FIONREAD, avail) == -1) JCL_ThrowException (env, IO_EXCEPTION, strerror (errno)); return avail; I'm not a FreeBSD expert, but I would have thought that it would support the FIONREAD ioctl. The FD may not be a file in this case, but I can't imagine what it would be otherwise, given the rest of the stack: at gnu.java.nio.VMChannel.available(VMChannel.java:144) at gnu.java.nio.FileChannelImpl.available(FileChannelImpl.java:188) at java.io.FileInputStream.available(FileInputStream.java:179) at java.io.FilterInputStream.available(FilterInputStream.java:129) at java.io.BufferedInputStream.read(BufferedInputStream.java:276) at java.io.FilterInputStream.read(FilterInputStream.java:173) at java.io.InputStreamReader.read(InputStreamReader.java:459) at java.io.BufferedReader.fill(BufferedReader.java:373) at java.io.BufferedReader.readLine(BufferedReader.java:475) at java.util.Properties.load(Properties.java:201) at java.util.PropertyResourceBundle.init (PropertyResourceBundle.java:109) at java.util.ResourceBundle.tryBundle(ResourceBundle.java:483) ...11 more So, can we use Classpath Tools when JamVM was compiled with --disable-zip option? As far as I know this should work. The gotcha here is likely the properties files, which the code was trying to read when it threw this exception. Do you have the file gnu/classpath/tools/common/Messages.properties in your share/classpath directory?
[commit-cp] classpath gnu/java/security/x509/ext/Certificat...
CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Casey Marshall rsdio 06/12/31 05:23:20 Modified files: gnu/java/security/x509/ext: CertificatePolicies.java IssuerAlternativeNames.java ExtendedKeyUsage.java GeneralNames.java Extension.java SubjectAlternativeNames.java gnu/java/security/x509: X509Certificate.java . : ChangeLog java/security/cert: X509CertSelector.java Added files: gnu/java/security/x509/ext: GeneralName.java NameConstraints.java GeneralSubtree.java Log message: 2006-12-30 Casey Marshall [EMAIL PROTECTED] * gnu/java/security/x509/X509Certificate.java (serialVersionUID): new constant. (extensions): parameterize. (getExtendedKeyUsage): parameterize return type. (getSubjectAlternativeNames): parameterize return type; handle changes to `SubjectAlternativeNames' class. (getIssuerAlternativeNames): parameterize return type; handle changes to `IssuerAlternativeNames' class. (getCriticalExtensionOIDs, getNonCriticalExtensionOIDs): parameterize return type. * gnu/java/security/x509/ext/CertificatePolicies.java (policies, policyQualifierInfos): parameterize. * gnu/java/security/x509/ext/ExtendedKeyUsage.java (purposeIds): parameterize. * gnu/java/security/x509/ext/Extension.java (init): add support for NameConstraints extension. * gnu/java/security/x509/ext/GeneralName.java: new class. * gnu/java/security/x509/ext/GeneralNames.java (names): parameterize; retrofit to use the GeneralName class. * gnu/java/security/x509/ext/GeneralSubtree.java: new class. * gnu/java/security/x509/ext/IssuerAlternativeNames.java (getNames): change return type to GeneralName parameterized list. * gnu/java/security/x509/ext/NameConstraints.java: new class. * gnu/java/security/x509/ext/SubjectAlternativeNames.java (getNames): change return type to GeneralName parameterized list. * java/security/cert/X509CertSelector.java: re-sorted methods. (makeName): new method. (addPathToName, addPathToName, getPathToNames, getPolicy, getSubjectAlternativeNames, setPathToNames, setPolicy): implemented. (keyPurposeSet, altNames, policy): parametized. (pathToNames): new field. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/security/x509/ext/CertificatePolicies.java?cvsroot=classpathr1=1.4r2=1.5 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/security/x509/ext/IssuerAlternativeNames.java?cvsroot=classpathr1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/security/x509/ext/ExtendedKeyUsage.java?cvsroot=classpathr1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/security/x509/ext/GeneralNames.java?cvsroot=classpathr1=1.6r2=1.7 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/security/x509/ext/Extension.java?cvsroot=classpathr1=1.7r2=1.8 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/security/x509/ext/SubjectAlternativeNames.java?cvsroot=classpathr1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/security/x509/ext/GeneralName.java?cvsroot=classpathrev=1.1 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/security/x509/ext/NameConstraints.java?cvsroot=classpathrev=1.1 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/security/x509/ext/GeneralSubtree.java?cvsroot=classpathrev=1.1 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/security/x509/X509Certificate.java?cvsroot=classpathr1=1.11r2=1.12 http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9029r2=1.9030 http://cvs.savannah.gnu.org/viewcvs/classpath/java/security/cert/X509CertSelector.java?cvsroot=classpathr1=1.9r2=1.10
Re: [cp-patches] java.util.Arrays fix
On Dec 13, 2006, at 12:56 AM, Marco Trudel wrote: Hey guys java.util.Arrays.binarySearch(Object[] a, Object key, Comparator c) exchanges a[i] and key, this can lead to ClassCastExceptions as shown in ComparatorTest.java. Arrays.patch fixes it. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30061
Re: [cp-patches] java.util.Arrays fix
On Dec 13, 2006, at 12:21 PM, David Daney wrote: Casey Marshall wrote: On Dec 13, 2006, at 12:56 AM, Marco Trudel wrote: Hey guys java.util.Arrays.binarySearch(Object[] a, Object key, Comparator c) exchanges a[i] and key, this can lead to ClassCastExceptions as shown in ComparatorTest.java. Arrays.patch fixes it. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30061 This exact problem bit me once. I developed code on the RI that inadvertently had a comparator that depended on the order of the arguments. I freely admit that my code was incorrect, but it did take me a while to figure out what was happening. I feel that if there is no performance penalty, then we should follow the behavior of the RI. I agree, since we have a patch. As long as it tests out OK, I'm not opposed to including it. In general I really urge against going out of our way to support behavior like this.
Re: [cp-patches] java.util.Arrays fix
On Dec 13, 2006, at 1:28 PM, Marco Trudel wrote: David Daney wrote: Casey Marshall wrote: In general I really urge against going out of our way to support behavior like this. Can you explain that further? You're against changes that - keep the specification as correct as they were before - will adapt classpath to the RI behavior - will prevent users from running into problems - restore old classpath behavior (regression fix) - have no negative side effects whatsoever Sorry if that seems to be a mean summary. This are just the points I'm seeing and I'm actually really surprised about the number and kind of reactions to that patch or that the mentioned bugreport has been closed as invalid. It is not a bug. 'Nuff said. I was replying to David, not to you. I would have assumed that someone says: Hey great, this only fixes problems and doesn't do anything bad. Let's commit it. Huh? Didn't I say that? My reply (which you trimmed away) said this: I agree, since we have a patch. As long as it tests out OK, I'm not opposed to including it. So as I said, I don't mean to offend you, I just can't follow why we wouldn't follow the RI when we still fulfill the specifications. I did say that I was against *going out of our way* to adhere to the precise behavior of the RI, when neither the spec nor the algorithms used require it. It's fine if you want to go looking for things like this, and writing fixes for them. These are not a bugs, though, and are not a priority. To be blunt about it, I don't care if you waste your time doing this, but I am not going to. I changed my mind! As a matter of principle, since I had to fix my code, everyone should have to suffer in the same manner, as their penalty for disobeying the mandates of the specification! :) Whaaat? David! I really hope - for the sake of humanity - that you're joking. Ah right, there's a :) at the end. I was so shocked from that statement that I missed it first... In this case, the Comparator is still wrong. It may work now with Classpath's binarySearch, but it is *in general* broken. If it gets used with some other algorithm, it may not work. HIDING BUGS IN CODE IS BAD.
[cp-patches] Re: RFC: Socket VM interface
On Dec 12, 2006, at 2:40 AM, Roman Kennke wrote:
Hi there,
I am not happy with the current situation wrt to the Socket related VM
interface. AFAICS, we have three layers of abstraction here:
- On API level we have the Socket/SocketImpl/SocketImplFactory stuff.
- Below this we have PlainSocketImpl and VMPlainSocketImpl et al.
- On the native side there is some kind of target layer too.
At least one of these layers seems superfluous. The VMSocketImpl class
seems to mostly map the methods from the SocketImpl class again.
I'd like to see the native target layer go away. I think the
minimum required to support user threads and blocking calls (like
what we do in NIO) should suffice.
Are there any objections to boiling down the VM interface to something
like:
class VMSockets
{
SocketImplFactory getSocketImplFactory();
DatagramSocketImplFactory getDatagramSocketImplFactory();
}
I think I see where you're going with this, and I agree that it would
be cleaner. The line where VMs need to take over, and where the
reference implementation will suffice, is a little blurry at the
moment. Defining it better should help out.
Of course, comments on how well this works for VM implementors who
can't use the POSIXy RI would be well appreciated here.
Thanks.
Re: RFC: Socket VM interface
On Dec 12, 2006, at 2:40 AM, Roman Kennke wrote:
Hi there,
I am not happy with the current situation wrt to the Socket related VM
interface. AFAICS, we have three layers of abstraction here:
- On API level we have the Socket/SocketImpl/SocketImplFactory stuff.
- Below this we have PlainSocketImpl and VMPlainSocketImpl et al.
- On the native side there is some kind of target layer too.
At least one of these layers seems superfluous. The VMSocketImpl class
seems to mostly map the methods from the SocketImpl class again.
I'd like to see the native target layer go away. I think the
minimum required to support user threads and blocking calls (like
what we do in NIO) should suffice.
Are there any objections to boiling down the VM interface to something
like:
class VMSockets
{
SocketImplFactory getSocketImplFactory();
DatagramSocketImplFactory getDatagramSocketImplFactory();
}
I think I see where you're going with this, and I agree that it would
be cleaner. The line where VMs need to take over, and where the
reference implementation will suffice, is a little blurry at the
moment. Defining it better should help out.
Of course, comments on how well this works for VM implementors who
can't use the POSIXy RI would be well appreciated here.
Thanks.
Re: [cp-patches] FYI: Use exception chaining in javax.net.ssl.SSLSocketFactory.getDefault()
On Dec 11, 2006, at 8:37 AM, Jeroen Frijters wrote: David Daney wrote: Jeroen Frijters wrote: throw new RuntimeException(error instantiating default socket factory: - + ex.toString()); That sounds more like an InternalError than the super-generic RuntimeException. Possibly. I don't know enough about this stuff to tell. I have, however, since discovered that the current code is wrong. When the factory is not properly configured it is supposed to return a factory that throws exceptions upon invocation of the factory methods, not at this stage. Really? That seems like worse behavior than just giving up when trying to create the factory. Just delaying exceptions like that seems like it will just hide bugs, instead of forcing you to deal with them up front. ...and yes, looking at the JavaDoc for 1.5 after writing that, they do say that it returns an inoperative factory on error. This makes no sense to me, but if that's what the RI does, then we should do it, too. I've got a patch (attached), but I'm going on vacation tomorrow and don't have time to properly test it and check it in, but if someone would like to do so, that would be great. I'll look at this, unless someone else wants to volunteer. Thanks.
Re: [cp-patches] Fix interrupted read/writes
On Dec 6, 2006, at 4:01 AM, Andrew Haley wrote: Casey Marshall writes: On Dec 5, 2006, at 2:52 AM, Andrew Haley wrote: The cpnio functions are (should be) trivial and inlined. What more is needed? Now, is VMChannel supposed to be POSIX-specific or not? If it is Yes, it is. supposed to be POSIX-specific, and there seem to be an awful lot of POSIXisms in there, why is it using cpio_connect() instead of simply connect(2)? I guessed that cpio_connect() was supposed to be a platform-independent abstraction on a syscall, but it isn't being used to do that: VMChannel.c isn't platform-independent. So cpio_connect() is useless, isn't it? No. This was trying to address the issues VM implementors had when it comes to user-space threads: syscalls that we use that can block indefinitely are wrapped in an easy-to-replace implementation, but otherwise the code assumes a POSIXy system. We went through this before. It seems that I didn't, anyway. Some of us may have discussed some of this on IRC/off list. I don't remember. I thought we had enough of a consensus that POSIX was a good enough abstraction for our reference implementation of the native code, as long as we left hooks like this in place for VMs when it comes to blocking IO calls. You'll notice that we don't do this for other functions that (according to the documentation) won't block. OH, OK. You are quite right: there is an explanation of this in javanio.h. So let me understand: this is to support a user-space threads package that requires special handling of blocking syscalls, perhaps one that doesn't provide wrappers for connect() _et al_. Yup. I seem to recall e.g. JikesRVM doing some LD_PRELOAD hackery to intercept blocking system calls. This should make that unnecessary, since all they need to do now is provide a different version of the cpnio_* functions. I would have preferred to simply omit the cpnio_* bits in the NIO changes I made, but a sufficient number of people did complain that this would not work well for green threaded VMs. And although these functions don't look like they will be inlined, they will because CPNIO_EXPORT is #defined static inline and javanio.c is #included by javanio.h. Yeah. Maybe the macro name isn't great, but in Classpath's version, it should be defined to inline those functions, since they're trivial. If some VM needed a more complicated implementation, they can #define CPNIO_EXPORT to be empty. Thanks.
Re: [cp-patches] [generics] Code-cleanup: remove unused imports
On Dec 6, 2006, at 2:49 PM, Tom Tromey wrote: Stefan == Stefan Huehner [EMAIL PROTECTED] writes: Stefan attached patch removes several unused import statement from Stefan generics-branch. Could you write a ChangeLog entry for this? And is your paperwork on file? Isn't this patch large but trivial? [*] Is copyright assignment really necessary? * http://www.gnu.org/prep/maintain/html_node/Legally- Significant.html#Legally-Significant
Re: [cp-patches] Fix interrupted read/writes
On Dec 5, 2006, at 2:52 AM, Andrew Haley wrote: Mark Wielaard writes: Hi, On Tue, 2006-12-05 at 11:04 +0100, Roman Kennke wrote: Except that you should probably also check if the thread was interrupted as the original patch does for read and write. I did it like that and it solved all my problems :-) But surely you have the same problem with any other callers of cpio_connect, or indeed cpio_*. You only fixed the bug in one place. Yeah I agree. I was wondering the same, but I decided to follow what Mark did and fix it in VMChannel. Maybe should pull all these fixes into javanio.c then? The only consumer is VMChannel. If you're going to loop around connect(2), you surely want to do so as close to the syscall as possible. The cpnio functions are (should be) trivial and inlined. What more is needed? Now, is VMChannel supposed to be POSIX-specific or not? If it is Yes, it is. supposed to be POSIX-specific, and there seem to be an awful lot of POSIXisms in there, why is it using cpio_connect() instead of simply connect(2)? I guessed that cpio_connect() was supposed to be a platform-independent abstraction on a syscall, but it isn't being used to do that: VMChannel.c isn't platform-independent. So cpio_connect() is useless, isn't it? No. This was trying to address the issues VM implementors had when it comes to user-space threads: syscalls that we use that can block indefinitely are wrapped in an easy-to-replace implementation, but otherwise the code assumes a POSIXy system. We went through this before. I thought we had enough of a consensus that POSIX was a good enough abstraction for our reference implementation of the native code, as long as we left hooks like this in place for VMs when it comes to blocking IO calls. You'll notice that we don't do this for other functions that (according to the documentation) won't block. Maybe I'm mistaken here. I'd like to hear opinions again from VM implementors on how well the cpnio stuff works for them. I think JikesRVM and Kaffe were the ones that offered user-space threading. native/jni/java-nio/javanio.h explains all of this.
Re: [cp-patches] Fix interrupted read/writes
On Dec 5, 2006, at 2:04 AM, Roman Kennke wrote: Am Dienstag, den 05.12.2006, 10:01 + schrieb Andrew Haley: Roman Kennke writes: I did it like that and it solved all my problems :-) But surely you have the same problem with any other callers of cpio_connect, or indeed cpio_*. You only fixed the bug in one place. Yeah I agree. I was wondering the same, but I decided to follow what Mark did and fix it in VMChannel. Maybe should pull all these fixes into javanio.c then? No. I explained this elsewhere, but that is not the point of the functions in javanio.c. The cpnio functions are meant to guarantee POSIX semantics, including the goofy errors you might get when using them; they only try to introduce an as-light-as-possible layer of insulation between the native code and blocking syscalls.
Re: [cp-patches] Fix interrupted read/writes
On Dec 4, 2006, at 11:19 AM, David Daney wrote:
Andrew Haley wrote:
Roman Kennke writes:
While testing eclipse I sometimes saw interrupted reads
occur. VMChannel
already had a mechanism for checking the interrupted status
of a thread
when a system call returned early. But this wasn't used for
the read()
and write() methods. This patch adds the logic. And makes my
eclipse
happy again :)
I am seeing a (possibly) related issue still:
java.net.SocketException: Interrupted system call
If connect(2) returns EINTR, you should retry:
CPNIO_EXPORT int
cpnio_connect (int fd, const struct sockaddr *addr, socklen_t
addrlen)
{
int retcode;
do
{
retcode = connect (fd, addr, addrlen);
}
while (retcode == EINTR);
return retcode;
}
Except that you should probably also check if the thread was
interrupted as the original patch does for read and write.
Also, it occurs to me that VMChannel.connect should just use select
for all cases -- right now, if no timeout is specified, it relies on
connect(2) blocking. In other cases, the socket is put into non-
blocking mode, and the timeout is applied in a call to select. Using
select for all cases would clean up that function a lot.
This call to select also looks like it needs EINTR protection.
Thanks.
Re: [cp-patches] RFC: fix JarEntry cert lookup
On Nov 27, 2006, at 12:08 AM, Raif S. Naffah wrote: On Sunday 26 November 2006 19:58, Casey Marshall wrote: On Nov 25, 2006, at 3:59 PM, Raif S. Naffah wrote: On Tuesday 21 November 2006 08:35, Casey Marshall wrote: ... This patch fixes an issue with JarEntry objects that are created before the entry is verified... ...before your patch our implementation outputs 0, 0, and 1, and after the patch: 1, 1, and 1 which is different in both cases. Yeah, JarEntry needs to check if the entry has been verified first before looking in the certificates map. Attached is an updated patch; with it the TestOfManifest test passes. yes. please update the copyright year of JarEntry when you check in the patch. OK. any reason why you didn't address the synchronization issue in JarEntry#getCertificates()? I wasn't sure if it was needed. I think when just reading the certs mapping, it doesn't need to be (that map is created when the manifest is read, and not modified after). But, the validity mapping probably needs synchronized access. I'll look at it. Thanks.
Re: [cp-patches] RFC: fix JarEntry cert lookup
On Nov 27, 2006, at 10:52 AM, Casey Marshall wrote:
On Nov 27, 2006, at 12:08 AM, Raif S. Naffah wrote:
any reason why you didn't address the synchronization issue in
JarEntry#getCertificates()?
I wasn't sure if it was needed.
It is needed, and JarFile explains that you need to lock on the
JarFile object when accessing that field.
I'm checking in this patch, thanks.
2006-11-27 Casey Marshall [EMAIL PROTECTED]
* java/util/jar/JarEntry.java (certs): removed.
(jarfile): new field.
(getCertificates): read the certificates from the containing JarFile.
* java/util/jar/JarFile.java (JarEnumeration.nextElement): don't
fill in 'certs,' fill in 'jarfile' for the entry.
(getEntry): likewise.
### Eclipse Workspace Patch 1.0
#P classpath
Index: java/util/jar/JarEntry.java
===
RCS file: /cvsroot/classpath/classpath/java/util/jar/JarEntry.java,v
retrieving revision 1.6
diff -u -r1.6 JarEntry.java
--- java/util/jar/JarEntry.java 2 Jul 2005 20:32:44 - 1.6
+++ java/util/jar/JarEntry.java 28 Nov 2006 00:02:54 -
@@ -1,5 +1,5 @@
/* JarEntry.java - Represents an entry in a jar file
- Copyright (C) 2000 Free Software Foundation, Inc.
+ Copyright (C) 2000, 2006 Free Software Foundation, Inc.
This file is part of GNU Classpath.
@@ -39,6 +39,7 @@
import java.io.IOException;
import java.security.cert.Certificate;
+import java.util.Set;
import java.util.zip.ZipEntry;
/**
@@ -60,7 +61,7 @@
// (Package local) fields
Attributes attr;
- Certificate certs[];
+ JarFile jarfile;
// Constructors
@@ -79,7 +80,7 @@
{
super(name);
attr = null;
-certs = null;
+jarfile = null;
}
/**
@@ -93,7 +94,7 @@
{
super(entry);
attr = null;
-certs = null;
+jarfile = null;
}
/**
@@ -112,7 +113,7 @@
catch (IOException _)
{
}
-certs = entry.getCertificates();
+jarfile = entry.jarfile;
}
// Methods
@@ -153,13 +154,19 @@
*/
public Certificate[] getCertificates()
{
-if (certs != null)
+if (jarfile != null)
{
- return (Certificate[])certs.clone();
- }
-else
- {
- return null;
+synchronized (jarfile)
+ {
+if (jarfile.entryCerts != null)
+ {
+Set certs = (Set) jarfile.entryCerts.get(getName());
+if (certs != null
+ jarfile.verified.get(getName()) == Boolean.TRUE)
+ return (Certificate[]) certs.toArray(new
Certificate[certs.size()]);
+ }
+ }
}
+return null;
}
}
Index: java/util/jar/JarFile.java
===
RCS file: /cvsroot/classpath/classpath/java/util/jar/JarFile.java,v
retrieving revision 1.23
diff -u -r1.23 JarFile.java
--- java/util/jar/JarFile.java 20 Nov 2006 09:28:49 - 1.23
+++ java/util/jar/JarFile.java 28 Nov 2006 00:02:55 -
@@ -382,19 +382,8 @@
}
jarfile.signaturesRead = true; // fudge it.
}
-
- // Include the certificates only if we have asserted that the
- // signatures are valid. This means the certificates will not be
- // available if the entry hasn't been read yet.
- if (jarfile.entryCerts != null
- jarfile.verified.get(zip.getName()) == Boolean.TRUE)
- {
- Set certs = (Set) jarfile.entryCerts.get(jar.getName());
- if (certs != null)
- jar.certs = (Certificate[])
- certs.toArray(new Certificate[certs.size()]);
- }
}
+ jar.jarfile = jarfile;
return jar;
}
}
@@ -439,18 +428,7 @@
}
signaturesRead = true;
}
- // See the comments in the JarEnumeration for why we do this
- // check.
- if (DEBUG)
- debug(entryCerts= + entryCerts + verified + name
- + ? + verified.get(name));
- if (entryCerts != null verified.get(name) == Boolean.TRUE)
- {
- Set certs = (Set) entryCerts.get(name);
- if (certs != null)
- jarEntry.certs = (Certificate[])
- certs.toArray(new Certificate[certs.size()]);
- }
+jarEntry.jarfile = this;
return jarEntry;
}
return null;
[commit-cp] classpath java/util/jar/JarEntry.java java/util...
CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Casey Marshall rsdio 06/11/28 00:07:59 Modified files: java/util/jar : JarEntry.java JarFile.java . : ChangeLog Log message: 2006-11-27Ê Casey MarshallÊ [EMAIL PROTECTED] * java/util/jar/JarEntry.java (certs): removed. (jarfile): new field. (getCertificates): read the certificates from the containing JarFile. * java/util/jar/JarFile.java (JarEnumeration.nextElement): don't fill in 'certs,' fill in 'jarfile' for the entry. (getEntry): likewise. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/java/util/jar/JarEntry.java?cvsroot=classpathr1=1.6r2=1.7 http://cvs.savannah.gnu.org/viewcvs/classpath/java/util/jar/JarFile.java?cvsroot=classpathr1=1.23r2=1.24 http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.8874r2=1.8875
Re: [cp-patches] RFC: fix JarEntry cert lookup
On Nov 25, 2006, at 3:59 PM, Raif S. Naffah wrote:
hello Casey,
On Tuesday 21 November 2006 08:35, Casey Marshall wrote:
...
This patch fixes an issue with JarEntry objects that are created
before the entry is verified: we used to bind the certificates to a
JarEntry at creation time, so if the entry has not been verified yet,
the certificates field will be null. This is contrary to the JDK
behavior.
This changes JarEntry to hold a pointer of its containing JarFile,
and getCertificates now just accesses the entryCerts field of
JarFile directly. Thus, once an entry is verified, its certificates
may be looked up with a previously-initialized entry...
i've added a new method to the Mauve test in
gnu/testlet/java/util/jar/JarFile/TestOfManifest.java to highlight
this
issue.
with both RI 1.4 (1.4.2_13) and 1.5 (1.5.0_09) the behavior is the
same: the
counts of certificates is 0, 1, and 1 respectively. before your
patch our
implementation outputs 0, 0, and 1, and after the patch: 1, 1, and
1 which is
different in both cases.
Yeah, JarEntry needs to check if the entry has been verified first
before looking in the certificates map. Attached is an updated patch;
with it the TestOfManifest test passes.
### Eclipse Workspace Patch 1.0
#P classpath
Index: java/util/jar/JarEntry.java
===
RCS file: /cvsroot/classpath/classpath/java/util/jar/JarEntry.java,v
retrieving revision 1.6
diff -u -r1.6 JarEntry.java
--- java/util/jar/JarEntry.java 2 Jul 2005 20:32:44 - 1.6
+++ java/util/jar/JarEntry.java 26 Nov 2006 08:39:02 -
@@ -39,6 +39,7 @@
import java.io.IOException;
import java.security.cert.Certificate;
+import java.util.Set;
import java.util.zip.ZipEntry;
/**
@@ -60,7 +61,7 @@
// (Package local) fields
Attributes attr;
- Certificate certs[];
+ JarFile jarfile;
// Constructors
@@ -79,7 +80,7 @@
{
super(name);
attr = null;
-certs = null;
+jarfile = null;
}
/**
@@ -93,7 +94,7 @@
{
super(entry);
attr = null;
-certs = null;
+jarfile = null;
}
/**
@@ -112,7 +113,7 @@
catch (IOException _)
{
}
-certs = entry.getCertificates();
+jarfile = entry.jarfile;
}
// Methods
@@ -153,13 +154,17 @@
*/
public Certificate[] getCertificates()
{
-if (certs != null)
+if (jarfile != null)
{
- return (Certificate[])certs.clone();
- }
-else
- {
- return null;
+// XXX synchronization???
+if (jarfile.entryCerts != null)
+ {
+Set certs = (Set) jarfile.entryCerts.get(getName());
+if (certs != null
+ jarfile.verified.get(getName()) == Boolean.TRUE)
+ return (Certificate[]) certs.toArray(new
Certificate[certs.size()]);
+ }
}
+return null;
}
}
Index: java/util/jar/JarFile.java
===
RCS file: /cvsroot/classpath/classpath/java/util/jar/JarFile.java,v
retrieving revision 1.23
diff -u -r1.23 JarFile.java
--- java/util/jar/JarFile.java 20 Nov 2006 09:28:49 - 1.23
+++ java/util/jar/JarFile.java 26 Nov 2006 08:39:02 -
@@ -382,19 +382,8 @@
}
jarfile.signaturesRead = true; // fudge it.
}
-
- // Include the certificates only if we have asserted that the
- // signatures are valid. This means the certificates will not be
- // available if the entry hasn't been read yet.
- if (jarfile.entryCerts != null
- jarfile.verified.get(zip.getName()) == Boolean.TRUE)
- {
- Set certs = (Set) jarfile.entryCerts.get(jar.getName());
- if (certs != null)
- jar.certs = (Certificate[])
- certs.toArray(new Certificate[certs.size()]);
- }
}
+ jar.jarfile = jarfile;
return jar;
}
}
@@ -439,18 +428,7 @@
}
signaturesRead = true;
}
- // See the comments in the JarEnumeration for why we do this
- // check.
- if (DEBUG)
- debug(entryCerts= + entryCerts + verified + name
- + ? + verified.get(name));
- if (entryCerts != null verified.get(name) == Boolean.TRUE)
- {
- Set certs = (Set) entryCerts.get(name);
- if (certs != null)
- jarEntry.certs = (Certificate[])
- certs.toArray(new Certificate[certs.size()]);
- }
+jarEntry.jarfile = this;
return jarEntry;
}
return null;
Re: SystemProperties secure?
On Nov 23, 2006, at 11:40 AM, Roman Kennke wrote:
We are using the SystemProperties class throughout the Classpath
code to
access system properties and avoid the security checks in
java.lang.System. However, I come to think that this is no good the
way
it is. This class is public and nothing prevents use of this class
from
application code. This way it'd very easy for an application to
cirumvent the protection in java.lang.System by using the
SystemProperties class directly. Not that I think that GNU Classpath
would be an interesting target for attacking, but shouldn't we avoid
such issues from the start? Please correct me if I missed some
important
aspect here.
The mechanism is all there, just some stuff is missing at the moment.
It seems like what we need to do is:
1. Provide reasonable defaults for the *security* properties
package.access and package.definition. These should include
gnu.classpath, at least. An alternative would be to *always* deny
certain package accesses/defintions in SecurityManager.checkPackageList.
2. The default Policy class should be gnu.java.security.PolicyFile
(which reads a real policy file) instead of
gnu.java.security.provider.DefaultPolicy (which allows everything).
The attached patch does this. The test case you posted to PR 29960
succeeds (by not allowing access to gnu.classpath.SystemProperties)
with it.
Cheers.
### Eclipse Workspace Patch 1.0
#P classpath
Index: java/security/Security.java
===
RCS file: /cvsroot/classpath/classpath/java/security/Security.java,v
retrieving revision 1.44
diff -u -r1.44 Security.java
--- java/security/Security.java 29 Apr 2006 06:16:09 - 1.44
+++ java/security/Security.java 25 Nov 2006 06:11:11 -
@@ -73,6 +73,9 @@
static
{
+ secprops.put(package.access, gnu.classpath.);
+ secprops.put(package.definition, gnu.classpath.);
+
String base = SystemProperties.getProperty(gnu.classpath.home.url);
String vendor =
SystemProperties.getProperty(gnu.classpath.vm.shortname);
Index: java/security/Policy.java
===
RCS file: /cvsroot/classpath/classpath/java/security/Policy.java,v
retrieving revision 1.14
diff -u -r1.14 Policy.java
--- java/security/Policy.java 19 Jan 2006 09:51:53 - 1.14
+++ java/security/Policy.java 25 Nov 2006 06:11:11 -
@@ -183,7 +183,7 @@
}
if (currentPolicy == null)
- currentPolicy = new gnu.java.security.provider.DefaultPolicy();
+ currentPolicy = new gnu.java.security.PolicyFile();
}
return currentPolicy;
}
Re: [cp-patches] more crypto fixes: JarFile
Marco Trudel wrote: Casey Marshall wrote: Marco Trudel wrote: Casey Marshall wrote: Marco Trudel wrote: snip Back to the patch. Comments? Hints? Your approach seems OK, but a hand-coded parser may still be faster (if only done once for the whole manifest, and if it uses a buffered stream, instead of reading a byte at a time) than using regexps for it. I don't think implementing a hand-coded parser is the right thing to do just because regexp is slow. This would need a lot of error-prone code and actually, regexp is here to do exactly parsing stuff like that. So instead of avoiding regexp because it's slow, it should be optimized (IMHO)... Sure. But you said yourself that you still thought the code was too slow, and I worry a little that your code may be fragile. I think it's too slow because of the crypto stuff. Parsing the manifest That's possible. We did a lot to optimize the symmetric crypto, but not the asymmetric stuff (that is, digital signatures). They rely on BigInteger, the Java version of which that's in Classpath has not been optimized, AFAIK. Again, Raif has a patch that uses the native GMP library, which is a lot faster. once isn't that much overhead. I still have problem that my code might be fragile, I see no more fragilness than we had before. Maybe you can explain that a little bit more in detail (see below). It's not more or less fragile, I'm just pointing out that it is (erm, might be). I do think it is a better approach than what we have now, though, so I think it should go in. I will try to take a look at the mainfest class next week. Maybe I can spare a couple of hours and do it right. So please do not yet commit it. OK. We can check this in now, though, regardless (beauty of CVS, etc.). I think I have a fix for the enumeration issue (JarEntry aren't reusable) too. No. The bytes used in the signature verification use the toByteArray method of ByteArrayOutputStream. The code may mistakenly not match the Name: line because it uses String.getBytes(). Yes, you create a byte[] by calling byteArrayOutputStream.toByteArray(). But later, you create the Name: entry this way: byte[] target = (Name: + entry.getName()).getBytes(); So you rely on the default byte representation as well. That's the only reason why I dared to do that too. Or do I miss something here? No, I wasn't saying the original code was correct. My point was that the original code doesn't introduce this conversion step for the bytes that are fed into the signature verifier, just for matching the Name: line; this would probably still produce false negatives just as often. And anyway, why repeat my mistakes? ;-) Also, I think the bikeshed should be painted Hunter Green.
Re: [cp-patches] more crypto fixes: JarFile
Marco Trudel wrote:
Hello list
I ran into some trouble when verifying signed jars:
1. it didn't work for classes with long names in jars
2. it was extremly slow
1.
Some (or all) Manifests seem to break lines longer than 70 characters
into multiple lines. The break is not always fix at 70 chars, I've seen
entries where the break is later. The following line(s) then start with
a space.
I can see that already in the header of my original
jface_3.2.0.I20060605-1400.jar (Manifest attached).
The same applies for Name/Digest pairs (the name only). So they might
look like this:
Name: org/eclipse/jface/bindings/keys/KeySequenceText$TraversalFilter.
class
SHA1-Digest: DxKojrJckHaMCrOyg+hgiOPi1PI=
Because such entries weren't supported, JarFile always told that these
files aren't signed. My patch adds support for that.
2.
Parsing the signatures of big Manifests was extremely slow. I assume
that's because it worked with single bytes and reparsed the whole
manifest for every file.
My patch changes that procedure. Now the manifest is parsed once with
some regexp and the result is reused.
Some little time experience on my computer:
Sun needs 0.4s to check the validity of the eclipse jface jar.
JarFile needs:
- unpatched: 36 seconds when used in a Sun JVM
- unpatched: 8 seconds when using a GCJ compiled exe
- patched: 0.7 seconds when using in a Sun JVM
- patched: 1 second when using in a GCJ compiled exe
It's still really slow compared to Sun. But at least not 9000% slower
(did I calculate that right?)...
Well, I wouldn't call that really slow -- that's a pretty huge
improvement. ISTR our regex implementation being slow, and our crypto
algs may not be optimized, either. Raif's native bignum patch may
improve this a bit.
Another thing I encountered but had no time to fix:
JarFile jarFile = new JarFile(something.jar);
Enumeration entries = jarFile.entries();
while(entries.hasMoreElements())
{
JarEntry entry = (JarEntry)entries.nextElement();
InputStream stream = jarFile.getInputStream(entry);
// read from the stream, that will parse the certificates
// the following works with a sun jvm.
// with classpath, one has to do the jarFile.entries() and loop
// again to be able to read the certs (this will always give null)
Certificate[] certs = entry.getCertificates();
}
It makes sense why this wouldn't work -- the JarEntry created for the
nextElement clause is probably initialized with a null certificates
list, because at that point the entry hasn't been verified. JarEntry
uses a private certificates field to store this, IIRC, not a callback
into its jar file.
I suppose it should be easy enough to change JarEntry to call into its
containing JarFile for that entry's certificates, instead of using a
field in JarEntry.
I also run into a regular expression bug, related to .* that included
newlines although the pattern was not in DOTALL mode. But,
unfortunately, I can't reproduce that anymore...
Back to the patch. Comments? Hints?
Your approach seems OK, but a hand-coded parser may still be faster (if
only done once for the whole manifest, and if it uses a buffered stream,
instead of reading a byte at a time) than using regexps for it. I'd also
be wary of byte[]-String-byte[] conversions, because you are wrapping
each entry+hash in a String, then using String.getBytes() (what if the
default character set is not what you expect?). This byte representation
must match what's in the file exactly, because it is used to verify the
entry.
It may make sense instead to change the Manifest class to retain the
byte-level representation of each entry, along with the hash value,
instead of re-parsing the manifest like this -- having two parsers for
the same thing is always trouble.
I'm not sure why I didn't try using the existing Manifest class when I
wrote the signed Jar stuff originally.
If there are no objections: Can someone commit that for me?
A changelog entry will follow shortly (at the latest by tomorrow
morning)...
thanks
Marco
PS: What's with the online mail archive? It stopped a couple of days
(weeks?) ago. It's really usefull having an updated archive online (for
google and discussion referencce).
Maybe it went on vacation along with Mark ;-)
Cheers.
Re: Signals, sockets and threads
Tom Tromey wrote: Guilhem == Guilhem Lavaux [EMAIL PROTECTED] writes: Guilhem 1) POSIX syscalls where originally written with no threads in Guilhem mind. glibc uses a trick to store errno in a thread local Guilhem storage using a special function. So the expected behaviour Guilhem of storing errno just after the accept is true only in this Guilhem case. If you use other type of threaded system then it may Guilhem not be right (or for example if the library is buggy). Do these systems exist? I was under the impression that this errno behavior was required by the posix threads spec. But I admit I don't have a definitive URL :-) Googling around a little seems to indicate that while yeah, systems *should* be errno-thread-safe, some just aren't. It also seems like defining _REENTRANT or _LIBC_REENTRANT should give you a thread-safe errno in some systems.
Re: Signals, sockets and threads
Guilhem Lavaux wrote: Casey Marshall wrote: Guilhem Lavaux wrote: In respect to this buggy interface, it is ok. :) I fail to see why this is buggy. Ok. 1) POSIX syscalls where originally written with no threads in mind. glibc uses a trick to store errno in a thread local storage using a special function. So the expected behaviour of storing errno just after the accept is true only in this case. If you use other type of threaded system then it may not be right (or for example if the library is buggy). Point. I said this on IRC, too, but I think the goal here should be to make it work on Linux first, then systems about as capable as Linux, then for the unwashed masses. If we need to use a thread-safe alternative to using errno directly, we can add that. 2) cpnio_* interface is duplicating the implementation of native-lib by abstracting some other syscalls. This is a bit burdensome because it is done in one library which is not really advertised as PLEASE REIMPLEMENT THIS IF YOU ARE NOT USING A USUAL POSIX SYSTEM LIKE LINUX. Point. This is really because I did the VMChannel work mostly before the native-lib changes were checked in; the cpnio functions were really meant to be a way for VMs to replace *blocking* syscalls. Ie, I don't expect that a VM implementor would need -- or want -- to re-implement every single POSIX call used by Classpath. The blocking-vs-non-blocking thing partly comes from some of the comments by the JikesRVM guys, and partly from reading man pages. If the split made here isn't correct, then we can address that. cpnio is more a re-implement this if you are stuck with a user thread library, but otherwise are using POSIX. 3) I am looking a bit at VMChannel.c and cpnio.c and there are some discrepency I see: somebody has created an interface for some syscalls but not some other. A VM implementor could not intercept all these calls easily and would end to add hooks in VMChannel.c (so to reimplement it). I mention the reason for this above. On the whole, it doesn't seem at all valuable to have a completely platform-independent native layer, because (1) it's simply hard to write such a beast, (2) using POSIX code is already pretty portable, and (3) that's the point of the VM layer, and we don't need yet another portability layer below that. The VMChannel native code is, I think you'll agree, extremely simple, and deliberately so. I think that maintaining that style throughout Classpath is the best way to do it. I could think also some strange cases like being able to translate errno before returning the syscall but you would argue we are dealing with posix systems (which is not entirely false). So, I would rather we use all the same interface (cpnet_* is nearly correct, maybe we can rename it to cpnio_* and add a few functions). Another possibility is that I am wrong in the philosophy that we want to put in the native implementation of classpath. But we are so near to have something a bit more general and portable that I cannot stand saying a few words about the current implementation. Again, my position is that the VM layer should be good enough for handling platform-specific stuff that can't be addressed within a POSIX-like API. Cheers.
Re: Signals, sockets and threads
Guilhem Lavaux wrote: Hi Robert, You are using tmp_errno = errno... ret is precisely holding errno. I Nope. 'ret' contains the return value of 'accept', which is not the same as 'errno'. have built the native-lib so that we are always thread safe. I have not noticed that VMChannel is so native-lib agnostic. ;-) I will have to rewrite VMChannel... Probably next weeks will be devoted to this. Why does NIO need to use the native-lib way at all? What, pray tell, is wrong with the POSIX way of doing things? Please don't rewrite VMChannel. If accessing 'errno' is not thread safe on some platforms (I think on Linux and Darwin it should be thread safe) then we should work around that. In respect to this buggy interface, it is ok. :) I fail to see why this is buggy.
Re: file locking problem in Java_gnu_java_nio_VMChannel_lock
Edwin Steiner wrote: On Wed, Oct 11, 2006 at 10:56:46AM -0600, Tom Tromey wrote: Edwin == Edwin Steiner [EMAIL PROTECTED] writes: Edwin The attached patch fixes this case. It is still Edwin not safe for len signed 32 bit. Looks ok to me, I'm going to check it in. I wrote a ChangeLog entry for you -- but please, next time, send one with a patch. Thanks! Sorry, I did not see my patch as a real solution, just as a quick fix, so I thought something else would finally be checked in. There is code duplication and all values signed 32-bit will fail, except for the max long value that is now checked. However, I don't know enough about classpath to solve these issues. Are we missing a #define of LARGEFILE_SOURCE or FILE_OFFSET_BITS=64?
[cp-patches] Re: preparation of VMPlainDatagramSocketImpl removal
Robert Schuster wrote: The other thing that is used from VMPlainDatagramSocketImpl is the connect() method. Is it possible for DGRAM sockets to just use VMChannel.connect instead? Yes. The original just called the common method _javanet_connect, anyway. Great. However there is just one little question left: java.net.SocketImpl.connect() throws IOException while java.net.DatagramImpl.connect() throws SocketException. I would have to change all throwings of IOException in VMChannel.connect to SocketExceptions and change affected signatures accordingly. Is this still ok? Yeah, throwing SocketException is better, in general. That's another nit about VMChannel -- those methods usually throw IOException, but the methods that wrap them only throw SocketException.
Re: preparation of VMPlainDatagramSocketImpl removal
Robert Schuster wrote: Hi all, hi Casey. As discussed earlier I am investigating the removal of the above class. In contrast to what I said in another mail I found two uses of the VMPlainDatagramSocketImpl. In PlainDatagramSocketImpl the IP_TTL field is used. This can be fixed by moving the constant into e.g VMPlainSocketImpl or VMChannel. When doing so the constant's name should be changed to something like CP_IP_TTL because it would otherwise conflict with a constant in the system headers when using the class in GCJ. Still there is something to find out: The IP_TTL constant is used for the VMPlainSocketImpl.setOption method. The JNI code for that method contains a big switch statement, but there is no case for IP_TTL. Should it simply be added? Yeah. What the setOption method tries to do now is put integer methods (those that set an integer or a boolean value) in one method (in VMPlainSocketImpl), and to get/set other values with dedicated methods. Getting the bind address, for example, has it's own method (getLocalAddress). This is probably not the best way to do this, though. This favors simpler native methods (always passing and returning an integer value is a lot easier than dealing with different argument types), but in this case I'm not satisfied with it. The other thing that is used from VMPlainDatagramSocketImpl is the connect() method. Is it possible for DGRAM sockets to just use VMChannel.connect instead? Yes. The original just called the common method _javanet_connect, anyway.
Re: [cp-patches] RFC: renamed method in KqueueSelectorImpl and removed IP_TTL field
Robert Schuster wrote: Hi, the attached patch renames a method in KqueueSelectorImpl (this conflicts with the field of the same name in GCJ) and removes the IP_TTL field in VMPlainDatagramSocketImpl. The latter is seemingly not used anywhere and causes a problem during GCJ compilation. Please comment whether this change is ok? Sure, the kqueue bits are fine (but, I'm at a loss at why they would be needed ;-) VMPlainDatagramSocketImpl is, I think, mostly deprecated at this point (favoring instead VMPlainSocketImpl, so more of the code is shared). I don't know if it's safe yet to remove it completely, though. I haven't looked. Thanks.
Re: [cp-patches] javax.crypto fixes
Marco Trudel wrote:
I fixed some stuff in javax.crypto:
Thanks for looking at this. Some of these parts of javax.crypto were
badly implemented, and I have to claim responsibility for that.
1. decryption with padding was broken/wrong handled
2. CipherOutputStream was completly broken/unusuable
3. PKCS7 did an unnecessary test
1. decryption with padding needs to keep back the last block for final
unpadding when doFinal() is called. This wasn't done. doFinal() lead to
an exception.
Actually, padded decrypting only worked correct when all data was passed
by doFinal(byte[]) or when there where update() calls that filled the
data to a multiple of the blocklengh and doFinal was called with the
rest of the data.
This fixes CiperInputStream as well, because it relies on the correct
doFinal() handling of the cipher class.
Understood. Sounds fine.
2. CipherOutputstream had a lot of code that did nothing except leading
to a NullPointerException when calling write(...) (outBuffer was never
initialized). It looks to me like the code should have worked around the
bugs in CipherAdapter. But that should have been done in
CipherInputStream?!
I don't know. I wrote all of these, so all I can do is claim ignorance
on how this stuff was supposed to work :-\
3. PKCS7 unpadding tested a value that was just read with itself. Fixed
it because I was already reading it... Nothing big...
OK.
Any comments? Hints?
It certainly looks more correct, to my eyes. I haven't tried this out
yet, but it looks much better, and certainly simpler.
I have no committing rights and the copyright assignment papers are not
yet arrived with mail. This might be a problem...
Yeah, we won't be able to accept this patch until you have a copyright
assignment on file. But if it is your intention to contribute this, then
it's just a matter of time.
Have we gotten you the correct forms? Maybe Mark can tell if this
process is moving forward or not.
@@ -447,16 +459,20 @@
break;
case IMode.DECRYPTION:
int padLen;
+byte[] buf3 = new byte[buf.length + partLen];
try
{
-padLen = pad.unpad(buf, 0, buf.length);
+if(partLen != 16) throw new WrongPaddingException();
What is this constant? Does this work for all block sizes and all
padding schemes?
[...]
+{
+ out.write(cipher.doFinal());
+ out.flush();
+ out.close();
+ } catch (javax.crypto.IllegalBlockSizeException ibse)
+ {
+ throw new IOException(ibse.toString());
+ } catch (javax.crypto.BadPaddingException bpe)
+ {
+ throw new IOException(bpe.toString());
+ }
It would be better to chain the exceptions here, and to omit the
explicit 'javax.crypto' package references (I know, they were in the
original).
[cp-patches] FYI: fix for PR 29190
This fixes some issues with the epoll selector, related to handling
canceled keys properly, and handling keys registered to closed channels.
I'm also taking the approach where the events byte buffer -- a direct
byte buffer whose pointer we pass directly to epoll_wait -- is allocated
once when the selector is created, and is reallocated as needed when new
keys are registered. We keep doubling the capacity as needed, until the
buffer grows to a certain size, then we start incrementally increasing
the capacity; if the capacity is more than twice what is needed, the
buffer is reallocated to half its current size. This should allocating
(potentially large) buffers on each call to select(), and shouldn't
waste too much memory.
2006-09-29 Casey Marshall [EMAIL PROTECTED]
PR 29190
* gnu/java/nio/EpollSelectionKeyImpl.java: extend
`AbstractSelectionKey.'
(cancel, isValid): removed.
* gnu/java/nio/EpollSelectorImpl.java (cancelledKeys): removed.
(events): new field.
(INITIAL_CAPACITY, MAX_DOUBLING_CAPACITY, CAPACITY_INCREMENT): new
fields.
(clinit): initialize those constants.
(init): don't initialize `cancelledKeys;' initialize `events.'
(doSelect): deregister cancelled keys; remove keys attached to
closed channels; wrap `epoll_wait' in `begin' and `end' calls; use
`events' buffer; reallocate `events' buffer if needed.
(register): reallocate `events' buffer if needed.
(reallocateBuffer): new method.
(cancel): removed.
Index: gnu/java/nio/EpollSelectionKeyImpl.java
===
RCS file: /cvsroot/classpath/classpath/gnu/java/nio/EpollSelectionKeyImpl.java,v
retrieving revision 1.1
diff -u -r1.1 EpollSelectionKeyImpl.java
--- gnu/java/nio/EpollSelectionKeyImpl.java 20 Sep 2006 21:39:41 -
1.1
+++ gnu/java/nio/EpollSelectionKeyImpl.java 30 Sep 2006 05:13:49 -
@@ -43,11 +43,12 @@
import java.nio.channels.SelectableChannel;
import java.nio.channels.SelectionKey;
import java.nio.channels.Selector;
+import java.nio.channels.spi.AbstractSelectionKey;
/**
* @author Casey Marshall ([EMAIL PROTECTED])
*/
-public class EpollSelectionKeyImpl extends SelectionKey
+public class EpollSelectionKeyImpl extends AbstractSelectionKey
{
final int fd;
private final EpollSelectorImpl selector;
@@ -67,15 +68,6 @@
}
/* (non-Javadoc)
- * @see java.nio.channels.SelectionKey#cancel()
- */
- public void cancel()
- {
-cancelled = true;
-selector.cancel(this);
- }
-
- /* (non-Javadoc)
* @see java.nio.channels.SelectionKey#channel()
*/
public SelectableChannel channel()
@@ -113,14 +105,6 @@
}
/* (non-Javadoc)
- * @see java.nio.channels.SelectionKey#isValid()
- */
- public boolean isValid()
- {
-return valid;
- }
-
- /* (non-Javadoc)
* @see java.nio.channels.SelectionKey#readyOps()
*/
public int readyOps()
Index: gnu/java/nio/EpollSelectorImpl.java
===
RCS file: /cvsroot/classpath/classpath/gnu/java/nio/EpollSelectorImpl.java,v
retrieving revision 1.4
diff -u -r1.4 EpollSelectorImpl.java
--- gnu/java/nio/EpollSelectorImpl.java 27 Sep 2006 21:30:44 - 1.4
+++ gnu/java/nio/EpollSelectorImpl.java 30 Sep 2006 05:13:49 -
@@ -42,6 +42,7 @@
import java.io.IOException;
import java.nio.ByteBuffer;
+import java.nio.channels.SelectableChannel;
import java.nio.channels.SelectionKey;
import java.nio.channels.Selector;
import java.nio.channels.spi.AbstractSelectableChannel;
@@ -75,8 +76,12 @@
private final HashMap keys;
private Set selectedKeys;
- private final Set cancelledKeys;
private Thread waitingThread;
+ private ByteBuffer events;
+
+ private static final int INITIAL_CAPACITY;
+ private static final int MAX_DOUBLING_CAPACITY;
+ private static final int CAPACITY_INCREMENT;
static
{
@@ -87,6 +92,10 @@
sizeof_struct_epoll_event = sizeof_struct();
else
sizeof_struct_epoll_event = -1;
+
+INITIAL_CAPACITY = 64 * sizeof_struct_epoll_event;
+MAX_DOUBLING_CAPACITY = 1024 * sizeof_struct_epoll_event;
+CAPACITY_INCREMENT = 128 * sizeof_struct_epoll_event;
}
public EpollSelectorImpl(SelectorProvider provider)
@@ -96,7 +105,7 @@
epoll_fd = epoll_create(DEFAULT_EPOLL_SIZE);
keys = new HashMap();
selectedKeys = null;
-cancelledKeys = new HashSet();
+events = ByteBuffer.allocateDirect(INITIAL_CAPACITY);
}
/* (non-Javadoc)
@@ -131,6 +140,7 @@
{
synchronized (keys)
{
+ Set cancelledKeys = cancelledKeys();
synchronized (cancelledKeys)
{
for (Iterator it = cancelledKeys.iterator(); it.hasNext(); )
@@ -140,25 +150,45 @@
key.valid = false;
keys.remove(Integer.valueOf(key.fd));
it.remove();
+deregister(key
[commit-cp] classpath ChangeLog gnu/java/nio/EpollSelection...
CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Casey Marshall rsdio 06/09/30 05:19:14 Modified files: . : ChangeLog gnu/java/nio : EpollSelectionKeyImpl.java EpollSelectorImpl.java Log message: 2006-09-29 Casey Marshall [EMAIL PROTECTED] PR 29190 * gnu/java/nio/EpollSelectionKeyImpl.java: extend `AbstractSelectionKey.' (cancel, isValid): removed. * gnu/java/nio/EpollSelectorImpl.java (cancelledKeys): removed. (events): new field. (INITIAL_CAPACITY, MAX_DOUBLING_CAPACITY, CAPACITY_INCREMENT): new fields. (clinit): initialize those constants. (init): don't initialize `cancelledKeys;' initialize `events.' (doSelect): deregister cancelled keys; remove keys attached to closed channels; wrap `epoll_wait' in `begin' and `end' calls; use `events' buffer; reallocate `events' buffer if needed. (register): reallocate `events' buffer if needed. (reallocateBuffer): new method. (cancel): removed. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.8635r2=1.8636 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/nio/EpollSelectionKeyImpl.java?cvsroot=classpathr1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/nio/EpollSelectorImpl.java?cvsroot=classpathr1=1.4r2=1.5
[commit-cp] classpath gnu/java/nio/KqueueSelectionKeyImpl.j...
CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Casey Marshall rsdio 06/09/27 21:19:31 Modified files: gnu/java/nio : KqueueSelectionKeyImpl.java KqueueSelectorImpl.java native/jni/java-nio: gnu_java_nio_KqueueSelectorImpl.c include: gnu_java_nio_KqueueSelectorImpl.h Log message: 2006-09-27 Casey Marshall [EMAIL PROTECTED] * gnu/java/nio/KqueueSelectionKeyImpl.java: extend AbstractSelectionKey. (nstate, valid, readEverEnabled, writeEverEnabled): removed. (activeOps, fd): new fields. (cancel): removed. (interestOps): just call `selector.setInterestOps.' (isValid): removed. (toString): include native fd in output. (hashCode, equals, isReadActive, isReadInterested, isWriteActive, isWriteInterested, needCommitRead, needCommitWrite): new methods. * gnu/java/nio/KqueueSelectorImpl.java (MAX_DOUBLING_CAPACITY, CAP_INCREMENT, INITIAL_CAPACITY): new constants. (cancelled): removed. (events): new field. (OP_ACCEPT, OP_CONNECT, OP_READ, OP_WRITE): new constants. (toString, equals): new methods. (doSelect): get cancelled keys from superclass; fix synchronization; initialize events that need to be added/deleted only when selecting; ignore keys attached to closed channels. (register): fix key initialization; synchronize adding keys. (setInterestOps): new method. (updateOps, updateOps): removed. (reallocateBuffer): new method. (doCancel): removed. (kevent_set): add index, active ops parameters; remove delete parameter. (kevent): add output space size parameter. * include/gnu_java_nio_KqueueSelectorImpl.h: regenerated. * native/jni/java-nio/gnu_java_nio_KqueueSelectorImpl.c (Java_gnu_java_nio_KqueueSelectorImpl_kevent_1set): only fill in one filter, at the given index. (Java_gnu_java_nio_KqueueSelectorImpl_kevent): separate incoming event count and outgoing event count. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/nio/KqueueSelectionKeyImpl.java?cvsroot=classpathr1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/nio/KqueueSelectorImpl.java?cvsroot=classpathr1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/java-nio/gnu_java_nio_KqueueSelectorImpl.c?cvsroot=classpathr1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/classpath/include/gnu_java_nio_KqueueSelectorImpl.h?cvsroot=classpathr1=1.1r2=1.2
[cp-patches] FYI: loopify scatter/gather file I/O
readScattering and writeGathering seem really unhappy on Darwin for
files, and calling the latter seems to return 0 too often (ie, all the
time). I don't know if this is a bug in those methods or not, but I
don't think it makes sense to use readv/writev for file I/O, when a loop
will suffice.
And, this makes Azureus extremely unhappy.
2006-09-24 Casey Marshall [EMAIL PROTECTED]
* gnu/java/nio/FileChannelImpl.java
(read): call `read' in a loop, don't use `readScattering.'
(write): call `write' in a loop, don't use `writeGathering.'
Committed.
### Eclipse Workspace Patch 1.0
#P classpath
Index: gnu/java/nio/FileChannelImpl.java
===
RCS file: /cvsroot/classpath/classpath/gnu/java/nio/FileChannelImpl.java,v
retrieving revision 1.17
diff -u -r1.17 FileChannelImpl.java
--- gnu/java/nio/FileChannelImpl.java 17 Sep 2006 07:31:41 - 1.17
+++ gnu/java/nio/FileChannelImpl.java 25 Sep 2006 06:44:06 -
@@ -253,7 +253,18 @@
public long read (ByteBuffer[] dsts, int offset, int length)
throws IOException
{
-return ch.readScattering(dsts, offset, length);
+int n = offset + length;
+long read = 0;
+if (offset 0 || length 0 || n dsts.length)
+ throw new ArrayIndexOutOfBoundsException();
+for (int i = offset; i n; i++)
+ {
+int ret = read(dsts[i]);
+if (ret == -1)
+ break;
+read += ret;
+ }
+return read;
}
public int write (ByteBuffer src) throws IOException
@@ -292,7 +303,13 @@
public long write(ByteBuffer[] srcs, int offset, int length)
throws IOException
{
-return ch.writeGathering(srcs, offset, length);
+int n = offset + length;
+long written = 0;
+if (offset 0 || length 0 || n srcs.length)
+ throw new ArrayIndexOutOfBoundsException();
+for (int i = offset; i n; i++)
+ written += write(srcs[i]);
+return written;
}
public MappedByteBuffer map (FileChannel.MapMode mode,
[cp-patches] FYI: fix writeGathering
If a gathering write (i.e., a write that takes an array of buffers) is
given a list of buffers, and the initial buffers have no remaining
elements, then the `write' method *should* skip these buffers, and use
the first buffer that has remaining elements.
Since on some operating systems, gathering writes can only take up to
sixteen input sources, it is important that we advance to some buffer
that has something in it. Otherwise, we'll see nothing in the first
sixteen buffers, and won't write anything.
This reverts my previous change to FileChannelImpl, since `writev' seems
to work OK on files. This should fix the issue I saw with Azureus, and
also clears two Mauve regressions I introduced (I think the tests are
wrong, but this fixes them regardless).
Scattering reads are probably also similarly broken; I'll look at that next.
2006-09-25 Casey Marshall [EMAIL PROTECTED]
* gnu/java/nio/FileChannelImpl.java (read): revert back to using
`readScattering.'
(write): revert back to using `writeGathering.'
* vm/reference/gnu/java/nio/VMChannel.java (writeGathering): find
the first buffer that has data remaining, and start at that one.
Committed.
### Eclipse Workspace Patch 1.0
#P classpath
Index: gnu/java/nio/FileChannelImpl.java
===
RCS file: /cvsroot/classpath/classpath/gnu/java/nio/FileChannelImpl.java,v
retrieving revision 1.18
diff -u -r1.18 FileChannelImpl.java
--- gnu/java/nio/FileChannelImpl.java 25 Sep 2006 06:49:18 - 1.18
+++ gnu/java/nio/FileChannelImpl.java 25 Sep 2006 21:44:16 -
@@ -253,18 +253,7 @@
public long read (ByteBuffer[] dsts, int offset, int length)
throws IOException
{
-int n = offset + length;
-long read = 0;
-if (offset 0 || length 0 || n dsts.length)
- throw new ArrayIndexOutOfBoundsException();
-for (int i = offset; i n; i++)
- {
-int ret = read(dsts[i]);
-if (ret == -1)
- break;
-read += ret;
- }
-return read;
+return ch.readScattering(dsts, offset, length);
}
public int write (ByteBuffer src) throws IOException
@@ -303,13 +292,7 @@
public long write(ByteBuffer[] srcs, int offset, int length)
throws IOException
{
-int n = offset + length;
-long written = 0;
-if (offset 0 || length 0 || n srcs.length)
- throw new ArrayIndexOutOfBoundsException();
-for (int i = offset; i n; i++)
- written += write(srcs[i]);
-return written;
+return ch.writeGathering(srcs, offset, length);
}
public MappedByteBuffer map (FileChannel.MapMode mode,
Index: vm/reference/gnu/java/nio/VMChannel.java
===
RCS file:
/cvsroot/classpath/classpath/vm/reference/gnu/java/nio/VMChannel.java,v
retrieving revision 1.2
diff -u -r1.2 VMChannel.java
--- vm/reference/gnu/java/nio/VMChannel.java17 Sep 2006 07:31:43 -
1.2
+++ vm/reference/gnu/java/nio/VMChannel.java25 Sep 2006 21:44:16 -
@@ -196,7 +196,7 @@
{
if (offset + length dsts.length)
throw new IndexOutOfBoundsException(offset + length dsts.length);
-
+
return readScattering(nfd.getNativeFD(), dsts, offset, length);
}
@@ -275,6 +275,21 @@
if (offset + length srcs.length)
throw new IndexOutOfBoundsException(offset + length srcs.length);
+// A gathering write is limited to 16 buffers; when writing, ensure
+// that we have at least one buffer with something in it in the 16
+// buffer window starting at offset.
+while (!srcs[offset].hasRemaining() offset srcs.length)
+ offset++;
+
+// There are no buffers with anything to write.
+if (offset == srcs.length)
+ return 0;
+
+// If we advanced `offset' so far that we don't have `length'
+// buffers left, reset length to only the remaining buffers.
+if (length srcs.length - offset)
+ length = srcs.length - offset;
+
return writeGathering(nfd.getNativeFD(), srcs, offset, length);
}
@@ -673,10 +688,10 @@
public String toString()
{
- if (!valid)
-return invalid;
if (closed)
return closed;
+ if (!valid)
+return invalid;
return String.valueOf(native_fd);
}
[commit-cp] classpath ChangeLog gnu/java/nio/FileChannelImp...
CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Casey Marshall rsdio 06/09/25 06:49:19 Modified files: . : ChangeLog gnu/java/nio : FileChannelImpl.java Log message: 2006-09-24 Casey Marshall [EMAIL PROTECTED] * gnu/java/nio/FileChannelImpl.java (read): call `read' in a loop, don't use `readScattering.' (write): call `write' in a loop, don't use `writeGathering.' CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.8606r2=1.8607 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/nio/FileChannelImpl.java?cvsroot=classpathr1=1.17r2=1.18
[cp-patches] FYI: more fixes for epoll selector
Here is another little fix for the epoll selector, which deals with the
epoll man pages not being exactly clear on what error values it returns.
I've been able to run Azureus, unmodified, on Ubuntu GNU/Linux with
jamvm! Even running on jamvm, it's really snappy.
The kqueue selector doesn't quite work as well, yet, but I'm looking at
this now.
2006-09-22 Casey Marshall [EMAIL PROTECTED]
* gnu/java/nio/EpollSelectorImpl.java (doSelect): remove keys
after we delete them.
(selectedKeys): return an empty set if nothing's been selected.
* native/jni/java-nio/gnu_java_nio_EpollSelectorImpl.c
(Java_gnu_java_nio_EpollSelectorImpl_epoll_1delete): don't
throw an exception on EBADF.
(Java_gnu_java_nio_EpollSelectorImpl_epoll_1wait): don't
throw exception on EINTR, just return 0.
Have fun.
### Eclipse Workspace Patch 1.0
#P classpath
Index: gnu/java/nio/EpollSelectorImpl.java
===
RCS file: /cvsroot/classpath/classpath/gnu/java/nio/EpollSelectorImpl.java,v
retrieving revision 1.2
diff -u -r1.2 EpollSelectorImpl.java
--- gnu/java/nio/EpollSelectorImpl.java 21 Sep 2006 23:23:02 - 1.2
+++ gnu/java/nio/EpollSelectorImpl.java 23 Sep 2006 06:39:20 -
@@ -139,6 +139,7 @@
epoll_delete(epoll_fd, key.fd);
key.valid = false;
keys.remove(new Integer(key.fd));
+it.remove();
}
// Don't bother if we have nothing to select.
@@ -177,6 +178,8 @@
*/
public Set selectedKeys()
{
+if (selectedKeys == null)
+ return Collections.EMPTY_SET;
return selectedKeys;
}
Index: native/jni/java-nio/gnu_java_nio_EpollSelectorImpl.c
===
RCS file:
/cvsroot/classpath/classpath/native/jni/java-nio/gnu_java_nio_EpollSelectorImpl.c,v
retrieving revision 1.2
diff -u -r1.2 gnu_java_nio_EpollSelectorImpl.c
--- native/jni/java-nio/gnu_java_nio_EpollSelectorImpl.c20 Sep 2006
22:28:08 - 1.2
+++ native/jni/java-nio/gnu_java_nio_EpollSelectorImpl.c23 Sep 2006
06:39:20 -
@@ -150,8 +150,8 @@
event.data.fd = fd;
#ifdef TRACE_EPOLL
- fprintf (stderr, %s: adding struct epoll_event { events: %o; data.fd: %d
}\n,
- __FUNCTION__, event.events, event.data.fd);
+ fprintf (stderr, %s: adding struct epoll_event { events: %o; data.fd: %d }
to %d\n,
+ __FUNCTION__, event.events, event.data.fd, efd);
#endif /* TRACE_EPOLL */
if (epoll_ctl (efd, EPOLL_CTL_ADD, fd, event) == -1)
@@ -197,8 +197,8 @@
event.data.fd = fd;
#ifdef TRACE_EPOLL
- fprintf (stderr, %s: modding struct epoll_event { events: %o; data.fd: %d
}\n,
- __FUNCTION__, event.events, event.data.fd);
+ fprintf (stderr, %s: modding struct epoll_event { events: %o; data.fd: %d }
on %d\n,
+ __FUNCTION__, event.events, event.data.fd, efd);
#endif /* TRACE_EPOLL */
if (epoll_ctl (efd, EPOLL_CTL_MOD, fd, event) == -1)
@@ -235,7 +235,7 @@
event.data.fd = fd;
#ifdef TRACE_EPOLL
- fprintf (stderr, %s: delete events on fd %d\n, __FUNCTION__, fd);
+ fprintf (stderr, %s: delete events on fd %d for %d\n, __FUNCTION__, fd,
efd);
#endif /* TRACE_EPOLL */
/* Older kernel versions require a non-null `event' parameter,
@@ -246,7 +246,11 @@
if (ENOSYS == errno)
JCL_ThrowException (env, java/lang/InternalError,
strerror (errno));
- else if (ENOENT == errno)
+ /* XXX the docs here seem a little strange. If `fd' is closed,
+ epoll_ctl returns EBADF; but the docs say that this happens
+ only when efd is invalid. Go figure.
+ */
+ else if (ENOENT == errno || EBADF == errno)
return; /* fd is closed; it's already removed. */
else
JCL_ThrowException (env, IO_EXCEPTION, strerror (errno));
@@ -282,16 +286,19 @@
}
#ifdef TRACE_EPOLL
- fprintf (stderr, %s: events: %p; num_events: %d; timeout: %d\n,
- __FUNCTION__, p, num_events, timeout);
+ fprintf (stderr, %s: events: %p; num_events: %d; timeout: %d; efd: %d\n,
+ __FUNCTION__, p, num_events, timeout, efd);
#endif /* TRACE_EPOLL */
ret = epoll_wait (efd, events, num_events, timeout);
+
if (ret == -1)
{
if (ENOSYS == errno)
JCL_ThrowException (env, java/lang/InternalError,
strerror (errno));
+ else if (EINTR == errno)
+ret = 0;
else
JCL_ThrowException (env, IO_EXCEPTION, strerror (errno));
}
Index: ChangeLog
===
RCS file: /cvsroot/classpath/classpath/ChangeLog,v
retrieving revision 1.8600
diff -u -r1.8600 ChangeLog
--- ChangeLog 23 Sep 2006 05:17:45 - 1.8600
+++ ChangeLog 23 Sep 2006 06:39:20 -
@@ -1,5 +1,16 @@
2006-09-22 Casey Marshall [EMAIL PROTECTED
[cp-patches] patch for PR 29190
Attached is a patch that *might* fix PR 29190. I don't have a Linux
system to test this on anymore :-(, so this may not work.
The issue was really that the epoll selector (and the kqueue selector,
now that I think about it) doesn't use the SPI interface correctly,
meaning that de-registering and canceling keys doesn't work quite right.
### Eclipse Workspace Patch 1.0
#P classpath
Index: gnu/java/nio/EpollSelectorImpl.java
===
RCS file: /cvsroot/classpath/classpath/gnu/java/nio/EpollSelectorImpl.java,v
retrieving revision 1.3
diff -u -r1.3 EpollSelectorImpl.java
--- gnu/java/nio/EpollSelectorImpl.java 23 Sep 2006 06:44:13 - 1.3
+++ gnu/java/nio/EpollSelectorImpl.java 24 Sep 2006 03:51:10 -
@@ -75,7 +75,6 @@
private final HashMap keys;
private Set selectedKeys;
- private final Set cancelledKeys;
private Thread waitingThread;
static
@@ -96,7 +95,6 @@
epoll_fd = epoll_create(DEFAULT_EPOLL_SIZE);
keys = new HashMap();
selectedKeys = null;
-cancelledKeys = new HashSet();
}
/* (non-Javadoc)
@@ -131,6 +129,7 @@
{
synchronized (keys)
{
+ Set cancelledKeys = cancelledKeys();
synchronized (cancelledKeys)
{
for (Iterator it = cancelledKeys.iterator(); it.hasNext(); )
@@ -140,6 +139,7 @@
key.valid = false;
keys.remove(new Integer(key.fd));
it.remove();
+deregister(key);
}
// Don't bother if we have nothing to select.
@@ -149,10 +149,19 @@
ByteBuffer selected =
ByteBuffer.allocateDirect(keys.size() * sizeof_struct_epoll_event);
-waitingThread = Thread.currentThread();
-int ret = epoll_wait(epoll_fd, selected, keys.size(), timeout);
-Thread.interrupted();
-waitingThread = null;
+int ret;
+try
+ {
+begin();
+waitingThread = Thread.currentThread();
+ret = epoll_wait(epoll_fd, selected, keys.size(), timeout);
+ }
+finally
+ {
+Thread.interrupted();
+waitingThread = null;
+end();
+ }
HashSet s = new HashSet(ret);
for (int i = 0; i ret; i++)
@@ -255,14 +264,6 @@
epoll_modify(epoll_fd, key.fd, ops);
}
- void cancel(EpollSelectionKeyImpl key)
- {
-synchronized (cancelledKeys)
-{
- cancelledKeys.add(key);
-}
- }
-
/**
* Tell if epoll is supported by this system, and support was compiled in.
*
Index: gnu/java/nio/EpollSelectionKeyImpl.java
===
RCS file: /cvsroot/classpath/classpath/gnu/java/nio/EpollSelectionKeyImpl.java,v
retrieving revision 1.1
diff -u -r1.1 EpollSelectionKeyImpl.java
--- gnu/java/nio/EpollSelectionKeyImpl.java 20 Sep 2006 21:39:41 -
1.1
+++ gnu/java/nio/EpollSelectionKeyImpl.java 24 Sep 2006 03:51:10 -
@@ -43,11 +43,12 @@
import java.nio.channels.SelectableChannel;
import java.nio.channels.SelectionKey;
import java.nio.channels.Selector;
+import java.nio.channels.spi.AbstractSelectionKey;
/**
* @author Casey Marshall ([EMAIL PROTECTED])
*/
-public class EpollSelectionKeyImpl extends SelectionKey
+public class EpollSelectionKeyImpl extends AbstractSelectionKey
{
final int fd;
private final EpollSelectorImpl selector;
@@ -67,15 +68,6 @@
}
/* (non-Javadoc)
- * @see java.nio.channels.SelectionKey#cancel()
- */
- public void cancel()
- {
-cancelled = true;
-selector.cancel(this);
- }
-
- /* (non-Javadoc)
* @see java.nio.channels.SelectionKey#channel()
*/
public SelectableChannel channel()
@@ -113,14 +105,6 @@
}
/* (non-Javadoc)
- * @see java.nio.channels.SelectionKey#isValid()
- */
- public boolean isValid()
- {
-return valid;
- }
-
- /* (non-Javadoc)
* @see java.nio.channels.SelectionKey#readyOps()
*/
public int readyOps()
[commit-cp] classpath gnu/java/nio/EpollSelectorImpl.java C...
CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Casey Marshall rsdio 06/09/23 06:44:15 Modified files: gnu/java/nio : EpollSelectorImpl.java . : ChangeLog native/jni/java-nio: gnu_java_nio_EpollSelectorImpl.c Log message: 2006-09-22 Casey Marshall [EMAIL PROTECTED] * gnu/java/nio/EpollSelectorImpl.java (doSelect): remove keys after we delete them. (selectedKeys): return an empty set if nothing's been selected. * native/jni/java-nio/gnu_java_nio_EpollSelectorImpl.c (Java_gnu_java_nio_EpollSelectorImpl_epoll_1delete): don't throw an exception on EBADF. (Java_gnu_java_nio_EpollSelectorImpl_epoll_1wait): don't throw exception on EINTR, just return 0. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/nio/EpollSelectorImpl.java?cvsroot=classpathr1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.8600r2=1.8601 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/java-nio/gnu_java_nio_EpollSelectorImpl.c?cvsroot=classpathr1=1.2r2=1.3
[cp-patches] FYI: fix VMFile.list on Darwin
Our usage of `readdir' wasn't portable: on Darwin, you get a NULL return
value, but `errno' will be zero. We were expecting errno to be nonzero
in that case.
This had the side effect that we'd keep reallocating the filename array,
because we'd be looping on the same value for `filename', and this would
exhaust memory.
I also took the liberty of adding a check for readdir_r, and use it in
cpio_readDir if it is available.
2006-09-22 Casey Marshall [EMAIL PROTECTED]
* configure.ac (AC_CHECK_FUNCS): check for `readdir_r.'
* native/jni/java-io/java_io_VMFile.c (Java_java_io_VMFile_list):
allocate `filename,' and handle changes to `cpio_readDir.'
* native/jni/native-lib/cpio.c (cpio_readDir): use `readdir_r' if
available; copy the filename into the destination buffer; return
an error code if readdir returns NULL, but errno is 0.
* native/jni/native-lib/cpio.h (cpio_readDir): change second
parameter to `const char *.'
Committed.
### Eclipse Workspace Patch 1.0
#P classpath
Index: native/jni/java-io/java_io_VMFile.c
===
RCS file: /cvsroot/classpath/classpath/native/jni/java-io/java_io_VMFile.c,v
retrieving revision 1.12
diff -u -r1.12 java_io_VMFile.c
--- native/jni/java-io/java_io_VMFile.c 21 Aug 2006 23:34:45 - 1.12
+++ native/jni/java-io/java_io_VMFile.c 23 Sep 2006 01:38:51 -
@@ -593,7 +593,7 @@
int result;
char **filelist;
void *handle;
- const char *filename;
+ const char *filename = (const char *) JCL_malloc (env, FILENAME_MAX);
unsigned long int filelist_count, max_filelist_count;
char **tmp_filelist;
jclass str_clazz;
@@ -630,7 +630,7 @@
max_filelist_count = REALLOC_SIZE;
/* read the files from the directory */
- result = cpio_readDir (handle, filename);
+ result = cpio_readDir (handle, filename);
while (result == CPNATIVE_OK)
{
if ((strcmp (filename, .) != 0) (strcmp (filename, ..) != 0))
@@ -666,9 +666,11 @@
}
/* read next directory entry */
- result = cpio_readDir (handle, filename);
+ result = cpio_readDir (handle, filename);
}
+ JCL_free (env, filename);
+
/* close directory */
result = cpio_closeDir (handle);
@@ -693,6 +695,9 @@
JCL_free (env, filelist);
return 0;
}
+
+ (*env)-DeleteLocalRef (env, str_clazz);
+
for (i = 0; i filelist_count; i++)
{
/* create new string */
Index: native/jni/native-lib/cpio.h
===
RCS file: /cvsroot/classpath/classpath/native/jni/native-lib/cpio.h,v
retrieving revision 1.2
diff -u -r1.2 cpio.h
--- native/jni/native-lib/cpio.h21 Aug 2006 23:34:46 - 1.2
+++ native/jni/native-lib/cpio.h23 Sep 2006 01:38:51 -
@@ -79,6 +79,6 @@
JNIEXPORT int cpio_openDir (const char *dirname, void **handle);
JNIEXPORT int cpio_closeDir (void *handle);
-JNIEXPORT int cpio_readDir (void *handle, const char **filename);
+JNIEXPORT int cpio_readDir (void *handle, const char *filename);
#endif
Index: native/jni/native-lib/cpio.c
===
RCS file: /cvsroot/classpath/classpath/native/jni/native-lib/cpio.c,v
retrieving revision 1.3
diff -u -r1.3 cpio.c
--- native/jni/native-lib/cpio.c31 Aug 2006 19:56:03 - 1.3
+++ native/jni/native-lib/cpio.c23 Sep 2006 01:38:51 -
@@ -448,14 +448,28 @@
}
-int cpio_readDir (void *handle, const char **filename)
+int cpio_readDir (void *handle, const char *filename)
{
+#ifdef HAVE_READDIR_R
+ struct dirent dent;
+#endif /* HAVE_READDIR_R */
struct dirent *dBuf;
+#ifdef HAVE_READDIR_R
+ readdir_r ((DIR *) handle, dent, dBuf);
+#else
dBuf = readdir((DIR *)handle);
+#endif /* HAVE_READDIR_R */
+
if (dBuf == NULL)
-return errno;
+{
+ /* Some OS's (OS X) return NULL on end-of-dir, but
+ don't set errno to anything. */
+ if (errno == 0)
+return ENOENT; /* Whatever. */
+ return errno;
+}
- *filename = dBuf-d_name;
+ strncpy (filename, dBuf-d_name, FILENAME_MAX);
return 0;
}
Index: configure.ac
===
RCS file: /cvsroot/classpath/classpath/configure.ac,v
retrieving revision 1.184
diff -u -r1.184 configure.ac
--- configure.ac20 Sep 2006 21:39:41 - 1.184
+++ configure.ac23 Sep 2006 01:38:51 -
@@ -375,7 +375,8 @@
mmap munmap mincore msync madvise getpagesize sysconf \
lstat readlink \
inet_aton inet_addr inet_pton \
- getifaddrs kqueue kevent epoll_create])
+ getifaddrs kqueue kevent epoll_create \
+ readdir_r ])
LIBMAGIC=
AC_CHECK_LIB(magic, magic_open, LIBMAGIC=-lmagic)
Re: [cp-patches] FYI: fix VMFile.list on Darwin
Casey Marshall wrote: Our usage of `readdir' wasn't portable: on Darwin, you get a NULL return value, but `errno' will be zero. We were expecting errno to be nonzero in that case. This had the side effect that we'd keep reallocating the filename array, because we'd be looping on the same value for `filename', and this would exhaust memory. I also took the liberty of adding a check for readdir_r, and use it in cpio_readDir if it is available. 2006-09-22 Casey Marshall [EMAIL PROTECTED] * configure.ac (AC_CHECK_FUNCS): check for `readdir_r.' * native/jni/java-io/java_io_VMFile.c (Java_java_io_VMFile_list): allocate `filename,' and handle changes to `cpio_readDir.' * native/jni/native-lib/cpio.c (cpio_readDir): use `readdir_r' if available; copy the filename into the destination buffer; return an error code if readdir returns NULL, but errno is 0. * native/jni/native-lib/cpio.h (cpio_readDir): change second parameter to `const char *.' Yup, this code introduced warnings. Fixed with this: 2006-09-22 Casey Marshall [EMAIL PROTECTED] * native/jni/java-io/java_io_VMFile.c (Java_java_io_VMFile_list): remove `const' from `filename.' * native/jni/native-lib/cpio.c (cpio_readDir): remove `const' from `filename.' * native/jni/native-lib/cpio.h (cpio_readDir): likewise.
[commit-cp] classpath native/jni/java-io/java_io_VMFile.c C...
CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Casey Marshall rsdio 06/09/23 01:45:30 Modified files: native/jni/java-io: java_io_VMFile.c . : ChangeLog configure.ac native/jni/native-lib: cpio.h cpio.c Log message: 2006-09-22 Casey Marshall [EMAIL PROTECTED] * configure.ac (AC_CHECK_FUNCS): check for `readdir_r.' * native/jni/java-io/java_io_VMFile.c (Java_java_io_VMFile_list): allocate `filename,' and handle changes to `cpio_readDir.' * native/jni/native-lib/cpio.c (cpio_readDir): use `readdir_r' if available; copy the filename into the destination buffer; return an error code if readdir returns NULL, but errno is 0. * native/jni/native-lib/cpio.h (cpio_readDir): change second parameter to `const char *.' CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/java-io/java_io_VMFile.c?cvsroot=classpathr1=1.12r2=1.13 http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.8598r2=1.8599 http://cvs.savannah.gnu.org/viewcvs/classpath/configure.ac?cvsroot=classpathr1=1.185r2=1.186 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/native-lib/cpio.h?cvsroot=classpathr1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/native-lib/cpio.c?cvsroot=classpathr1=1.3r2=1.4
[commit-cp] classpath native/jni/java-io/java_io_VMFile.c C...
CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Casey Marshall rsdio 06/09/23 05:17:46 Modified files: native/jni/java-io: java_io_VMFile.c . : ChangeLog native/jni/native-lib: cpio.h cpio.c Log message: 2006-09-22 Casey Marshall [EMAIL PROTECTED] * native/jni/java-io/java_io_VMFile.c (Java_java_io_VMFile_list): remove `const' from `filename.' * native/jni/native-lib/cpio.c (cpio_readDir): remove `const' from `filename.' * native/jni/native-lib/cpio.h (cpio_readDir): likewise. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/java-io/java_io_VMFile.c?cvsroot=classpathr1=1.13r2=1.14 http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.8599r2=1.8600 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/native-lib/cpio.h?cvsroot=classpathr1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/native-lib/cpio.c?cvsroot=classpathr1=1.4r2=1.5
[cp-patches] FYI: Epoll and DatagramSocket bugs
Paul Jenner helpfully pointed out some problems when running Azureus
with the epoll selector, and the modified DatagramSocket implementation.
2006-09-21 Casey Marshall [EMAIL PROTECTED]
* gnu/java/net/PlainDatagramSocketImpl.java (send): ignore
`InterruptedIOException;' try again if it gets thrown.
(receive): likewise, but re-throw `SocketTimeoutException.'
* gnu/java/nio/EpollSelectorImpl.java (doSelect): just return 0
if we have nothing to select.
Committed.
### Eclipse Workspace Patch 1.0
#P classpath
Index: gnu/java/nio/EpollSelectorImpl.java
===
RCS file: /cvsroot/classpath/classpath/gnu/java/nio/EpollSelectorImpl.java,v
retrieving revision 1.1
diff -u -r1.1 EpollSelectorImpl.java
--- gnu/java/nio/EpollSelectorImpl.java 20 Sep 2006 21:39:41 - 1.1
+++ gnu/java/nio/EpollSelectorImpl.java 21 Sep 2006 23:16:22 -
@@ -140,6 +140,10 @@
key.valid = false;
keys.remove(new Integer(key.fd));
}
+
+// Don't bother if we have nothing to select.
+if (keys.isEmpty())
+ return 0;
ByteBuffer selected =
ByteBuffer.allocateDirect(keys.size() * sizeof_struct_epoll_event);
Index: gnu/java/net/PlainDatagramSocketImpl.java
===
RCS file:
/cvsroot/classpath/classpath/gnu/java/net/PlainDatagramSocketImpl.java,v
retrieving revision 1.11
diff -u -r1.11 PlainDatagramSocketImpl.java
--- gnu/java/net/PlainDatagramSocketImpl.java 17 Sep 2006 07:31:41 -
1.11
+++ gnu/java/net/PlainDatagramSocketImpl.java 21 Sep 2006 23:16:22 -
@@ -41,6 +41,7 @@
import gnu.java.nio.VMChannel;
import java.io.IOException;
+import java.io.InterruptedIOException;
import java.lang.reflect.Field;
import java.net.DatagramPacket;
import java.net.DatagramSocketImpl;
@@ -49,6 +50,7 @@
import java.net.NetworkInterface;
import java.net.SocketAddress;
import java.net.SocketException;
+import java.net.SocketTimeoutException;
import java.nio.ByteBuffer;
/**
@@ -259,7 +261,17 @@
throw new NullPointerException();
if (port = 0)
throw new SocketException(invalid port + port);
-channel.send(buf, new InetSocketAddress(remote, port));
+while (true)
+ {
+try
+ {
+channel.send(buf, new InetSocketAddress(remote, port));
+ }
+catch (InterruptedIOException ioe)
+ {
+// Ignore; interrupted system call.
+ }
+ }
}
}
@@ -278,7 +290,23 @@
ByteBuffer buf = ByteBuffer.wrap(packet.getData(),
packet.getOffset(),
packet.getLength());
-SocketAddress addr = channel.receive(buf);
+SocketAddress addr = null;
+while (true)
+ {
+try
+ {
+addr = channel.receive(buf);
+break;
+ }
+catch (SocketTimeoutException ste)
+ {
+throw ste;
+ }
+catch (InterruptedIOException iioe)
+ {
+// Ignore. Loop.
+ }
+ }
if (addr != null)
packet.setSocketAddress(addr);
packet.setLength(buf.position() - packet.getOffset());
Re: [cp-patches] FYI: Epoll and DatagramSocket bugs
David Daney wrote:
Casey Marshall wrote:
-channel.send(buf, new InetSocketAddress(remote, port));
+while (true)
+ {
+try
+ {
+channel.send(buf, new InetSocketAddress(remote, port));
+ }
+catch (InterruptedIOException ioe)
+ {
+// Ignore; interrupted system call.
+ }
+ }
}
How does the while loop exit?
Just wondering,
At the `break' statement I forgot to insert :-)
[commit-cp] classpath gnu/java/nio/EpollSelectorImpl.java C...
CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Casey Marshall rsdio 06/09/21 23:23:03 Modified files: gnu/java/nio : EpollSelectorImpl.java . : ChangeLog gnu/java/net : PlainDatagramSocketImpl.java Log message: 2006-09-21 csm [EMAIL PROTECTED] * gnu/java/net/PlainDatagramSocketImpl.java (send): ignore `InterruptedIOException;' try again if it gets thrown. (receive): likewise, but re-throw `SocketTimeoutException.' * gnu/java/nio/EpollSelectorImpl.java (doSelect): just return 0 if we have nothing to select. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/nio/EpollSelectorImpl.java?cvsroot=classpathr1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.8590r2=1.8591 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/net/PlainDatagramSocketImpl.java?cvsroot=classpathr1=1.11r2=1.12
[commit-cp] classpath/gnu/java/net PlainDatagramSocketImpl....
CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Casey Marshall rsdio 06/09/22 00:11:56 Modified files: gnu/java/net : PlainDatagramSocketImpl.java Log message: Missed from previous checkin. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/net/PlainDatagramSocketImpl.java?cvsroot=classpathr1=1.12r2=1.13
Re: [cp-patches] FYI: Fix distcheck for native/jni/java-nio
Mark Wielaard wrote: + gnu_java_nio_channels_FileChannelImpl.c \ This is obsolete, and FileChannelImpl now contains no native methods. I know I shoulda removed the file, but I wield `cvs rm' with care.
[cp-patches] FYI: fix SocketChannelImpl.isConnected
Jeroen helped flush a brain fart out of my head; this patch fixes the
definition of `isConnected' in SocketChannel -- if we have a connection
pending, meaning that we initiated a nonblocking connect, which did not
succeed immediately, and finishConnect was not called after the
connection completes, then we should return false for `isConnected.'
2006-09-20 Casey Marshall [EMAIL PROTECTED]
* gnu/java/nio/SocketChannelImpl.java (finishConnect): don't
call `isConnected.'
(isConnected): return false if `connectionPending' is true.
Committed.
### Eclipse Workspace Patch 1.0
#P classpath
Index: ChangeLog
===
RCS file: /cvsroot/classpath/classpath/ChangeLog,v
retrieving revision 1.8577
diff -u -r1.8577 ChangeLog
--- ChangeLog 20 Sep 2006 18:26:24 - 1.8577
+++ ChangeLog 20 Sep 2006 21:04:45 -
@@ -1,3 +1,9 @@
+2006-09-20 Casey Marshall [EMAIL PROTECTED]
+
+ * gnu/java/nio/SocketChannelImpl.java (finishConnect): don't
+ call `isConnected.'
+ (isConnected): return false if `connectionPending' is true.
+
2006-09-20 Francis Kung [EMAIL PROTECTED]
PR 29011
Index: gnu/java/nio/SocketChannelImpl.java
===
RCS file: /cvsroot/classpath/classpath/gnu/java/nio/SocketChannelImpl.java,v
retrieving revision 1.30
diff -u -r1.30 SocketChannelImpl.java
--- gnu/java/nio/SocketChannelImpl.java 17 Sep 2006 07:31:41 - 1.30
+++ gnu/java/nio/SocketChannelImpl.java 20 Sep 2006 21:04:45 -
@@ -175,14 +175,15 @@
connectionPending = !connected;
return connected;
}
-
- public boolean finishConnect ()
+
+ public boolean finishConnect()
throws IOException
{
if (!isOpen())
throw new ClosedChannelException();
-
-if (isConnected())
+
+InetSocketAddress remote = channel.getPeerAddress();
+if (remote != null)
{
connectionPending = false;
return true;
@@ -196,6 +197,10 @@
public boolean isConnected()
{
+// Wait until finishConnect is called before transitioning to
+// connected.
+if (connectionPending)
+ return false;
try
{
InetSocketAddress remote = channel.getPeerAddress();
[cp-patches] FYI: epoll selector
I'm checking this in. I won't be able to test if the fallback code works
on 2.4 kernels, however.
2006-09-20 Casey Marshall [EMAIL PROTECTED]
* configure.ac (AC_CHECK_HEADERS): check for `sys/epoll.h.'
(AC_CHECK_FUNCS): check for `epoll_create.'
* gnu/java/nio/EpollSelectionKeyImpl.java: new file.
* gnu/java/nio/EpollSelectorImpl.java: new file.
* gnu/java/nio/SelectorProviderImpl.java (epoll_failed): new
class field.
(openSelector): return epoll selector if requested and
available.
* include/Makefile.am (H_FILES): add
gnu_java_nio_EpollSelectorImpl.h.
(gnu_java_nio_EpollSelectorImpl.h): new target.
* include/gnu_java_nio_EpollSelectorImpl.h: new file.
* native/jni/java-nio/Makefile.am (libjavanio_la_SOURCES): add
gnu_java_nio_EpollSelectorImpl.c.
* native/jni/java-nio/gnu_java_nio_EpollSelectorImpl.c: new
file.
### Eclipse Workspace Patch 1.0
#P classpath
Index: include/Makefile.am
===
RCS file: /cvsroot/classpath/classpath/include/Makefile.am,v
retrieving revision 1.70
diff -u -r1.70 Makefile.am
--- include/Makefile.am 17 Sep 2006 07:31:41 - 1.70
+++ include/Makefile.am 20 Sep 2006 21:32:43 -
@@ -128,6 +128,7 @@
$(top_srcdir)/include/gnu_java_net_VMPlainDatagramSocketImpl.h \
$(top_srcdir)/include/gnu_java_net_VMPlainSocketImpl.h \
$(top_srcdir)/include/gnu_java_net_local_LocalSocketImpl.h \
+$(top_srcdir)/include/gnu_java_nio_EpollSelectorImpl.h \
$(top_srcdir)/include/gnu_java_nio_FileChannelImpl.h \
$(top_srcdir)/include/gnu_java_nio_KqueueSelectorImpl.h \
$(top_srcdir)/include/gnu_java_nio_VMChannel.h \
@@ -227,6 +228,9 @@
$(top_srcdir)/include/gnu_java_nio_KqueueSelectorImpl.h:
$(top_srcdir)/gnu/java/nio/KqueueSelectorImpl.java
$(JAVAH) -o $@ gnu.java.nio.KqueueSelectorImpl
+$(top_srcdir)/include/gnu_java_nio_EpollSelectorImpl.h:
$(top_srcdir)/gnu/java/nio/EpollSelectorImpl.java
+ $(JAVAH) -o $@ gnu.java.nio.EpollSelectorImpl
+
$(top_srcdir)/include/gnu_java_nio_charset_iconv_IconvDecoder.h:
$(top_srcdir)/gnu/java/nio/charset/iconv/IconvDecoder.java
$(JAVAH) -o $@ gnu.java.nio.charset.iconv.IconvDecoder
$(top_srcdir)/include/gnu_java_nio_charset_iconv_IconvEncoder.h:
$(top_srcdir)/gnu/java/nio/charset/iconv/IconvEncoder.java
Index: gnu/java/nio/SelectorProviderImpl.java
===
RCS file: /cvsroot/classpath/classpath/gnu/java/nio/SelectorProviderImpl.java,v
retrieving revision 1.9
diff -u -r1.9 SelectorProviderImpl.java
--- gnu/java/nio/SelectorProviderImpl.java 17 Sep 2006 07:31:41 -
1.9
+++ gnu/java/nio/SelectorProviderImpl.java 20 Sep 2006 21:32:43 -
@@ -53,6 +53,7 @@
private static final String SELECTOR_IMPL_KQUEUE = kqueue;
private static final String SELECTOR_IMPL_EPOLL = epoll;
private static final String SELECTOR_IMPL = gnu.java.nio.selectorImpl;
+ private static boolean epoll_failed = false;
public SelectorProviderImpl ()
{
@@ -76,12 +77,31 @@
String selectorImpl = default;
if (KqueueSelectorImpl.kqueue_supported())
selectorImpl = SELECTOR_IMPL_KQUEUE;
+if (EpollSelectorImpl.epoll_supported() !epoll_failed)
+ selectorImpl = SELECTOR_IMPL_EPOLL;
selectorImpl = SystemProperties.getProperty(SELECTOR_IMPL, selectorImpl);
if (selectorImpl.equals(SELECTOR_IMPL_KQUEUE))
return new KqueueSelectorImpl(this);
+
if (selectorImpl.equals(SELECTOR_IMPL_EPOLL))
- throw new UnsupportedOperationException(epoll selector not yet
implemented);
+ {
+// We jump through these hoops because even though epoll may look
+// like it's available (sys/epoll.h exists, and you can link against
+// all the epoll functions) it may not be available in the kernel
+// (especially 2.4 kernels), meaning you will get ENOSYS at run time.
+//
+// Madness!
+try
+ {
+return new EpollSelectorImpl(this);
+ }
+catch (InternalError e)
+ {
+// epoll_create throws this on ENOSYS.
+epoll_failed = true;
+ }
+ }
return new SelectorImpl (this);
}
Index: configure.ac
===
RCS file: /cvsroot/classpath/classpath/configure.ac,v
retrieving revision 1.183
diff -u -r1.183 configure.ac
--- configure.ac17 Sep 2006 07:31:41 - 1.183
+++ configure.ac20 Sep 2006 21:32:43 -
@@ -357,7 +357,7 @@
fcntl.h \
sys/mman.h \
magic.h \
-sys/event.h])
+sys/event.h sys/epoll.h])
AC_EGREP_HEADER(uint32_t, stdint.h, AC_DEFINE(HAVE_INT32_DEFINED, 1, [Define
to 1 if you have uint32_t]))
AC_EGREP_HEADER(uint32_t, inttypes.h
[cp-patches] FYI: epoll: deleting closed file descriptors
A file descriptor is removed from an epoll descriptor when it is closed; trying to remove it later harmlessly returns ENOENT. This handles that case. 2006-09-20 Casey Marshall [EMAIL PROTECTED] * native/jni/java-nio/gnu_java_nio_EpollSelectorImpl.c (Java_gnu_java_nio_EpollSelectorImpl_epoll_1delete): ignore ENOENT. Committed. ### Eclipse Workspace Patch 1.0 #P classpath Index: native/jni/java-nio/gnu_java_nio_EpollSelectorImpl.c === RCS file: /cvsroot/classpath/classpath/native/jni/java-nio/gnu_java_nio_EpollSelectorImpl.c,v retrieving revision 1.1 diff -u -r1.1 gnu_java_nio_EpollSelectorImpl.c --- native/jni/java-nio/gnu_java_nio_EpollSelectorImpl.c20 Sep 2006 21:39:41 - 1.1 +++ native/jni/java-nio/gnu_java_nio_EpollSelectorImpl.c20 Sep 2006 22:21:33 - @@ -246,6 +246,8 @@ if (ENOSYS == errno) JCL_ThrowException (env, java/lang/InternalError, strerror (errno)); + else if (ENOENT == errno) +return; /* fd is closed; it's already removed. */ else JCL_ThrowException (env, IO_EXCEPTION, strerror (errno)); }
[cp-patches] FYI: mention epoll selectors in NEWS
2006-09-20 Casey Marshall [EMAIL PROTECTED] * NEWS: mention epoll selector along with the kqueue one. ### Eclipse Workspace Patch 1.0 #P classpath Index: NEWS === RCS file: /cvsroot/classpath/classpath/NEWS,v retrieving revision 1.168 diff -u -r1.168 NEWS --- NEWS17 Sep 2006 07:31:41 - 1.168 +++ NEWS20 Sep 2006 22:33:58 - @@ -19,9 +19,9 @@ * Added aton method to vm/reference/java/net/VMInetAddress.java. * NetworkInterface has been implemented for systems that provide the `getifaddrs' function. -* A java.nio.channels.Selector implementation based on the - kqueue/kevent notification mechanism has been added for Mac OS X and - BSD systems. +* java.nio.channels.Selector implementations have been added that use + the kqueue notification mechanism on Mac OS X and *BSD, and that use + the epoll notification mechanism on Linux 2.6. * java.nio has been refactored to support more non-blocking operations natively. Blocking IO classes have been refactored to call non-blocking classes. Non-blocking accepts, connects, and
[commit-cp] classpath gnu/java/nio/SocketChannelImpl.java C...
CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Casey Marshall rsdio 06/09/20 21:06:57 Modified files: gnu/java/nio : SocketChannelImpl.java . : ChangeLog Log message: 2006-09-20 Casey Marshall [EMAIL PROTECTED] * gnu/java/nio/SocketChannelImpl.java (finishConnect): don't call `isConnected.' (isConnected): return false if `connectionPending' is true. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/nio/SocketChannelImpl.java?cvsroot=classpathr1=1.30r2=1.31 http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.8577r2=1.8578
[commit-cp] classpath include/Makefile.am gnu/java/nio/Sele...
CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Casey Marshall rsdio 06/09/20 21:39:41 Modified files: include: Makefile.am gnu/java/nio : SelectorProviderImpl.java . : ChangeLog configure.ac native/jni/java-nio: Makefile.am Added files: include: gnu_java_nio_EpollSelectorImpl.h gnu/java/nio : EpollSelectorImpl.java EpollSelectionKeyImpl.java native/jni/java-nio: gnu_java_nio_EpollSelectorImpl.c Log message: 2006-09-20 Casey Marshall [EMAIL PROTECTED] * configure.ac (AC_CHECK_HEADERS): check for `sys/epoll.h.' (AC_CHECK_FUNCS): check for `epoll_create.' * gnu/java/nio/EpollSelectionKeyImpl.java: new file. * gnu/java/nio/EpollSelectorImpl.java: new file. * gnu/java/nio/SelectorProviderImpl.java (epoll_failed): new class field. (openSelector): return epoll selector if requested and available. * include/Makefile.am (H_FILES): add gnu_java_nio_EpollSelectorImpl.h. (gnu_java_nio_EpollSelectorImpl.h): new target. * include/gnu_java_nio_EpollSelectorImpl.h: new file. * native/jni/java-nio/Makefile.am (libjavanio_la_SOURCES): add gnu_java_nio_EpollSelectorImpl.c. * native/jni/java-nio/gnu_java_nio_EpollSelectorImpl.c: new file. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/include/Makefile.am?cvsroot=classpathr1=1.70r2=1.71 http://cvs.savannah.gnu.org/viewcvs/classpath/include/gnu_java_nio_EpollSelectorImpl.h?cvsroot=classpathrev=1.1 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/nio/SelectorProviderImpl.java?cvsroot=classpathr1=1.9r2=1.10 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/nio/EpollSelectorImpl.java?cvsroot=classpathrev=1.1 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/nio/EpollSelectionKeyImpl.java?cvsroot=classpathrev=1.1 http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.8578r2=1.8579 http://cvs.savannah.gnu.org/viewcvs/classpath/configure.ac?cvsroot=classpathr1=1.183r2=1.184 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/java-nio/Makefile.am?cvsroot=classpathr1=1.26r2=1.27 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/java-nio/gnu_java_nio_EpollSelectorImpl.c?cvsroot=classpathrev=1.1
[commit-cp] classpath ChangeLog NEWS
CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Casey Marshall rsdio 06/09/20 22:35:55 Modified files: . : ChangeLog NEWS Log message: 2006-09-20 Casey Marshall [EMAIL PROTECTED] * NEWS: mention epoll selector along with the kqueue one. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.8581r2=1.8582 http://cvs.savannah.gnu.org/viewcvs/classpath/NEWS?cvsroot=classpathr1=1.168r2=1.169
Re: [cp-patches] RFC: epoll-based selector
David Daney wrote: Casey Marshall wrote: Here is a patch to implement a Selector using the epoll_wait call on Linux, the preferred event notification facility in the 2.6 series kernels. This seems to test OK, so I'll probably just commit this soon. It compiles OK on systems that do and don't have epoll, and on Linux the Mauve tests for Selector pass. I have not tested the patch, but am afraid that it may fail on linux systems without epoll support (2.4.x kernels I think lack epoll). I am running glibc-2.3.3 which has sys/epoll.h but I think that the epoll syscalls may fail at runtime with ENOSYS. Also I am running gcj/libgcj cross compiler and do not know how this patch will interact with libgcj. Well those are my concerns. I guess if things get broken by this we can add a configure switch to manually disable it. Thanks for mentioning this. I suppose I should have known that trying to write software for Linux would be a minefield of crap like this :-\ Does libgcj use Classpath's NIO? I thought for a lot of these things libgcj had its own implementation in CNI. Note, too, that you can disable epoll (or kqueue) at run time by setting the system property gnu.java.nio.selectorImpl to any string other than epoll (or kqueue), and use the old select() based version. Maybe we can detect ENOSYS at run time, and disable epoll selectors. Thanks.
Re: [cp-patches] RFC: epoll-based selector
Casey Marshall wrote:
Note, too, that you can disable epoll (or kqueue) at run time by setting
the system property gnu.java.nio.selectorImpl to any string other than
epoll (or kqueue), and use the old select() based version. Maybe we
can detect ENOSYS at run time, and disable epoll selectors.
OK. I've attached a revised patch that tries epoll selectors if support
was compiled in, and if that fails with ENOSYS, we set a flag that
disables trying it again. In any case, if creating an epoll selector
fails, we fall back on the select- (actually, whatever backs VMSelector)
based version.
Warning, I've neither tried, nor tried to compile, this yet.
### Eclipse Workspace Patch 1.0
#P classpath
Index: include/Makefile.am
===
RCS file: /cvsroot/classpath/classpath/include/Makefile.am,v
retrieving revision 1.70
diff -u -r1.70 Makefile.am
--- include/Makefile.am 17 Sep 2006 07:31:41 - 1.70
+++ include/Makefile.am 19 Sep 2006 21:46:56 -
@@ -128,6 +128,7 @@
$(top_srcdir)/include/gnu_java_net_VMPlainDatagramSocketImpl.h \
$(top_srcdir)/include/gnu_java_net_VMPlainSocketImpl.h \
$(top_srcdir)/include/gnu_java_net_local_LocalSocketImpl.h \
+$(top_srcdir)/include/gnu_java_nio_EpollSelectorImpl.h \
$(top_srcdir)/include/gnu_java_nio_FileChannelImpl.h \
$(top_srcdir)/include/gnu_java_nio_KqueueSelectorImpl.h \
$(top_srcdir)/include/gnu_java_nio_VMChannel.h \
@@ -227,6 +228,9 @@
$(top_srcdir)/include/gnu_java_nio_KqueueSelectorImpl.h:
$(top_srcdir)/gnu/java/nio/KqueueSelectorImpl.java
$(JAVAH) -o $@ gnu.java.nio.KqueueSelectorImpl
+$(top_srcdir)/include/gnu_java_nio_EpollSelectorImpl.h:
$(top_srcdir)/gnu/java/nio/EpollSelectorImpl.java
+ $(JAVAH) -o $@ gnu.java.nio.EpollSelectorImpl
+
$(top_srcdir)/include/gnu_java_nio_charset_iconv_IconvDecoder.h:
$(top_srcdir)/gnu/java/nio/charset/iconv/IconvDecoder.java
$(JAVAH) -o $@ gnu.java.nio.charset.iconv.IconvDecoder
$(top_srcdir)/include/gnu_java_nio_charset_iconv_IconvEncoder.h:
$(top_srcdir)/gnu/java/nio/charset/iconv/IconvEncoder.java
Index: gnu/java/nio/SelectorProviderImpl.java
===
RCS file: /cvsroot/classpath/classpath/gnu/java/nio/SelectorProviderImpl.java,v
retrieving revision 1.9
diff -u -r1.9 SelectorProviderImpl.java
--- gnu/java/nio/SelectorProviderImpl.java 17 Sep 2006 07:31:41 -
1.9
+++ gnu/java/nio/SelectorProviderImpl.java 19 Sep 2006 21:46:56 -
@@ -53,6 +53,7 @@
private static final String SELECTOR_IMPL_KQUEUE = kqueue;
private static final String SELECTOR_IMPL_EPOLL = epoll;
private static final String SELECTOR_IMPL = gnu.java.nio.selectorImpl;
+ private static boolean epoll_failed = false;
public SelectorProviderImpl ()
{
@@ -76,12 +77,31 @@
String selectorImpl = default;
if (KqueueSelectorImpl.kqueue_supported())
selectorImpl = SELECTOR_IMPL_KQUEUE;
+if (EpollSelectorImpl.epoll_supported() !epoll_failed)
+ selectorImpl = SELECTOR_IMPL_EPOLL;
selectorImpl = SystemProperties.getProperty(SELECTOR_IMPL, selectorImpl);
if (selectorImpl.equals(SELECTOR_IMPL_KQUEUE))
return new KqueueSelectorImpl(this);
+
if (selectorImpl.equals(SELECTOR_IMPL_EPOLL))
- throw new UnsupportedOperationException(epoll selector not yet
implemented);
+ {
+// We jump through these hoops because even though epoll may look
+// like it's available (sys/epoll.h exists, and you can link against
+// all the epoll functions) it may not be available in the kernel
+// (especially 2.4 kernels), meaning you will get ENOSYS at run time.
+//
+// Madness!
+try
+ {
+return new EpollSelectorImpl(this);
+ }
+catch (InternalError e)
+ {
+// epoll_create throws this on ENOSYS.
+epoll_failed = true;
+ }
+ }
return new SelectorImpl (this);
}
Index: configure.ac
===
RCS file: /cvsroot/classpath/classpath/configure.ac,v
retrieving revision 1.183
diff -u -r1.183 configure.ac
--- configure.ac17 Sep 2006 07:31:41 - 1.183
+++ configure.ac19 Sep 2006 21:46:56 -
@@ -357,7 +357,7 @@
fcntl.h \
sys/mman.h \
magic.h \
-sys/event.h])
+sys/event.h sys/epoll.h])
AC_EGREP_HEADER(uint32_t, stdint.h, AC_DEFINE(HAVE_INT32_DEFINED, 1, [Define
to 1 if you have uint32_t]))
AC_EGREP_HEADER(uint32_t, inttypes.h, AC_DEFINE(HAVE_INT32_DEFINED, 1,
[Define to 1 if you have uint32_t]))
@@ -375,7 +375,7 @@
mmap munmap mincore msync madvise getpagesize sysconf \
lstat readlink \
inet_aton inet_addr inet_pton \
- getifaddrs kqueue kevent
Re: [cp-patches] RFC: epoll-based selector
Anthony Green wrote: On Mon, 2006-09-18 at 18:38 -0700, Casey Marshall wrote: Here is a patch to implement a Selector using the epoll_wait call on Linux, the preferred event notification facility in the 2.6 series kernels. This is great Casey. Have you ever tried running Azureus? It stresses both the nio selector code as well as our crypto infrastructure -- two areas where you are expert. I realize that GNU Classpath != libgcj, but it's worth mentioning that azureus still doesn't run nearly as smoothly on gcj as it does on Sun java. I blame nio and crypto, but I don't have any proof :-) I'm curious to hear how azureus fares on vanilla GNU Classpath (vs Sun, for instance). I haven't run Azureus on classpath or GCJ yet. I'd actually be surprised if the epoll selector even makes a difference in that app (even if Classpath's default selector does some just plain inefficient things), unless you really are interacting with thousands of peers at once.
Re: Classpath and gnu-crypto
What version of GCJ are you using? In recent releases of GCJ (or maybe the upcoming release -- I haven't been tracking this) GNU Crypto is a part of libgcj. Like Raif wrote in his reply, replacing gnu.crypto with gnu.java.security in your code will work in a newer GCJ release. Compiling Classpath itself with an existing GCJ will likely not do what you want. You *should* be able to compile the gnu-crypto Jar to an .so, however. The command line for that would be something like this: gcj -shared -o libgnu-crypto.so gnu-crypto.jar Then you should be able to link your program against libgnu-crypto.so. You may also find more help with GCJ on their mailing list: see http://gcc.gnu.org/lists.html, the GCJ mailing list is [EMAIL PROTECTED].
Re: [cp-patches] Patch: RFC: enable 1.4 methods in jessie
Tom Tromey wrote: I'd like some comment before committing this. An FC bug report led to this note: http://www.mail-archive.com/jessie-discuss@nongnu.org/msg00059.html This patch is simply the same thing, applied to Classpath. Any reason this should not go in? No reason. It looks fine. Thanks for tracking this.
[cp-patches] Re: RFC: small nio change
Jeroen Frijters wrote: Hi Casey, I would like to remove the dependence on VMChannel from Socket and ServerSocket (as this breaks the layering). Do you agree with this patch? I think this should be OK. Refresh my memory, though: in ServerSocket and Socket `impl' is created in a constructor, right? And it is only set to null in close, right? Because otherwise testing `impl == null' won't make a correct definition of isClosed(). Thanks.
[cp-patches] FYI: remove debug printf
Removes an errant debug printf. 2006-09-18 Casey Marshall [EMAIL PROTECTED] * native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c (Java_gnu_java_net_VMPlainSocketImpl_listen): remove debug printf. ### Eclipse Workspace Patch 1.0 #P classpath Index: native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c === RCS file: /cvsroot/classpath/classpath/native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c,v retrieving revision 1.7 diff -u -r1.7 gnu_java_net_VMPlainSocketImpl.c --- native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c17 Sep 2006 07:31:43 - 1.7 +++ native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c19 Sep 2006 01:24:21 - @@ -155,7 +155,6 @@ /* listen is not a blocking system call */ if ((ret = listen (fd, backlog)) == -1) JCL_ThrowException (env, IO_EXCEPTION, strerror (errno)); - printf(listen returns %d\n, ret); }
[cp-patches] RFC: epoll-based selector
from your version. */
+
+
+package gnu.java.nio;
+
+import gnu.classpath.Configuration;
+
+import java.io.IOException;
+import java.nio.ByteBuffer;
+import java.nio.channels.SelectionKey;
+import java.nio.channels.Selector;
+import java.nio.channels.spi.AbstractSelectableChannel;
+import java.nio.channels.spi.AbstractSelector;
+import java.nio.channels.spi.SelectorProvider;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.HashSet;
+import java.util.Iterator;
+import java.util.Set;
+
+/**
+ * An implementation of [EMAIL PROTECTED] Selector} that uses the epoll event
+ * notification mechanism on GNU/Linux.
+ *
+ * @author Casey Marshall ([EMAIL PROTECTED])
+ */
+public class EpollSelectorImpl extends AbstractSelector
+{
+ // XXX is this reasonable? Does it matter?
+ private static final int DEFAULT_EPOLL_SIZE = 128;
+ private static final int sizeof_struct_epoll_event;
+
+ private static final int OP_ACCEPT = SelectionKey.OP_ACCEPT;
+ private static final int OP_CONNECT = SelectionKey.OP_CONNECT;
+ private static final int OP_READ= SelectionKey.OP_READ;
+ private static final int OP_WRITE = SelectionKey.OP_WRITE;
+
+ /** our epoll file descriptor. */
+ private int epoll_fd;
+
+ private final HashMap keys;
+ private Set selectedKeys;
+ private final Set cancelledKeys;
+ private Thread waitingThread;
+
+ static
+ {
+if (Configuration.INIT_LOAD_LIBRARY)
+ System.loadLibrary(javanio);
+
+if (epoll_supported())
+ sizeof_struct_epoll_event = sizeof_struct();
+else
+ sizeof_struct_epoll_event = -1;
+ }
+
+ public EpollSelectorImpl(SelectorProvider provider)
+throws IOException
+ {
+super(provider);
+epoll_fd = epoll_create(DEFAULT_EPOLL_SIZE);
+keys = new HashMap();
+selectedKeys = null;
+cancelledKeys = new HashSet();
+ }
+
+ /* (non-Javadoc)
+ * @see java.nio.channels.Selector#keys()
+ */
+ public Set keys()
+ {
+return new HashSet(keys.values());
+ }
+
+ /* (non-Javadoc)
+ * @see java.nio.channels.Selector#select()
+ */
+ public int select() throws IOException
+ {
+return doSelect(-1);
+ }
+
+ /* (non-Javadoc)
+ * @see java.nio.channels.Selector#select(long)
+ */
+ public int select(long timeout) throws IOException
+ {
+if (timeout Integer.MAX_VALUE)
+ throw new IllegalArgumentException(timeout is too large);
+if (timeout 0)
+ throw new IllegalArgumentException(invalid timeout);
+return doSelect((int) timeout);
+ }
+
+ private int doSelect(int timeout) throws IOException
+ {
+synchronized (keys)
+{
+ synchronized (cancelledKeys)
+ {
+for (Iterator it = cancelledKeys.iterator(); it.hasNext(); )
+ {
+EpollSelectionKeyImpl key = (EpollSelectionKeyImpl) it.next();
+epoll_delete(epoll_fd, key.fd);
+key.valid = false;
+keys.remove(new Integer(key.fd));
+ }
+
+ByteBuffer selected =
+ ByteBuffer.allocateDirect(keys.size() * sizeof_struct_epoll_event);
+
+waitingThread = Thread.currentThread();
+int ret = epoll_wait(epoll_fd, selected, keys.size(), timeout);
+Thread.interrupted();
+waitingThread = null;
+
+HashSet s = new HashSet(ret);
+for (int i = 0; i ret; i++)
+ {
+selected.position(i * sizeof_struct_epoll_event);
+ByteBuffer b = selected.slice();
+int fd = selected_fd(b);
+EpollSelectionKeyImpl key
+ = (EpollSelectionKeyImpl) keys.get(new Integer(fd));
+if (key == null)
+ throw new IOException(fd was selected, but no key found);
+key.selectedOps = selected_ops(b) key.interestOps;
+s.add(key);
+ }
+selectedKeys = s;
+return ret;
+ }
+}
+ }
+
+ /* (non-Javadoc)
+ * @see java.nio.channels.Selector#selectedKeys()
+ */
+ public Set selectedKeys()
+ {
+return selectedKeys;
+ }
+
+ /* (non-Javadoc)
+ * @see java.nio.channels.Selector#selectNow()
+ */
+ public int selectNow() throws IOException
+ {
+return doSelect(0);
+ }
+
+ /* (non-Javadoc)
+ * @see java.nio.channels.Selector#wakeup()
+ */
+ public Selector wakeup()
+ {
+try
+ {
+waitingThread.interrupt();
+ }
+catch (NullPointerException npe)
+ {
+ }
+return this;
+ }
+
+ /* (non-Javadoc)
+ * @see java.nio.channels.spi.AbstractSelector#implCloseSelector()
+ */
+ protected void implCloseSelector() throws IOException
+ {
+VMChannel.close(epoll_fd);
+ }
+
+ /* (non-Javadoc)
+ * @see
java.nio.channels.spi.AbstractSelector#register(java.nio.channels.spi.AbstractSelectableChannel,
int, java.lang.Object)
+ */
+ protected SelectionKey register(AbstractSelectableChannel ch, int ops,
Object att)
+ {
+if (!(ch instanceof VMChannelOwner))
+ throw new IllegalArgumentException
[commit-cp] classpath ChangeLog native/jni/java-net/gnu_jav...
CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Casey Marshall rsdio 06/09/19 01:28:47 Modified files: . : ChangeLog native/jni/java-net: gnu_java_net_VMPlainSocketImpl.c Log message: 2006-09-18 Casey Marshall [EMAIL PROTECTED] * native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c (Java_gnu_java_net_VMPlainSocketImpl_listen): remove debug printf. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.8562r2=1.8563 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c?cvsroot=classpathr1=1.7r2=1.8
[cp-patches] FYI: big IO, net, NIO change
OK. Hibbego. I'm checking in my patch that I've been writing about recently. Again, the patch itself is large, so I'll just post a link to it: http://metastatic.org/source/io-nio-final.patch To summarize, this patch: * Implements most non-blocking operations for real -- that is, using native function calls on file descriptors in non-blocking mode. Blocking-IO APIs now defer to the NIO API, in blocking mode. * Refactors our code and the VM interfaces to keep no native state (such as file descriptor integers) in core classes, but instead in VM classes. A number of VM classes have, unfortunately, been modified to support this, but I think in general these changes are for the best. * Implements NetworkInterface using getifaddrs. * Adds a Selector that uses kqueue, the preferred event notification mechanism on OS X. There is more work to do here. In particular, too much code in the core classes knows about file descriptor integers; this too should be moved to the VM classes. Also, an epoll-based selector for Linux would be nice to have. If this breaks anything at all (the Mauve tests I've run, on OS X and Linux, seem to show that this code works well) please complain (fiercely if you must ;-) to me about it. It's a little uncouth to check in such a large patch, sure, but I think this is the good and correct way to implement IO in Java. I've updated NEWS to explain these changes. The change log is also large, but detailed about lots of little changes: 2006-09-16 Casey Marshall [EMAIL PROTECTED] * NEWS: updated. * configure.ac (AC_CHECK_HEADERS): check for `sys/event.h'. (AC_CHECK_FUNCS): add checks for readv, writev, getifaddrs, kqueue, and kevent. (HAVE_INET6): define if IPv6 is supported. * gnu/java/net/PlainDatagramSocketImpl.java (channel): new field. (native_fd): removed. (impl): new field. (init): throw IOException; initialize fields. (finalize): removed. (getNativeFD): removed. (bind): use `PlainSocketImpl.bind.' (create): use `PlainSocketImpl.initSocket.' (disconnect): use `PlainSocketImpl.disconnect.' (getLocalPort): new method. (send): use `VMChannel.send.' (receive): use `VMChannel.receive.' (setOption): use `PlainSocketImpl.setOption.' (getOption): use `PlainSocketImpl.getOption.' (close): use `VMChannel.State.close.' (join): use `PlainSocketImpl.join.' (leave): use `PlainSocketImpl.leave.' (joinGroup, leaveGroup): implemented. * gnu/java/net/PlainSocketImpl.java: make non-final. (native_fd): removed. (impl): new field. (channel): new field. (init): initialize `impl.' (finalize, getNativeFD): removed. (setOption): use `PlainSocketImpl.setOption.' (getOption): use `PlainSocketImpl.getOption.' (shutdownInput): use `PlainSocketImpl.shutdownInput.' (shutdownOutput): use `PlainSocketImpl.shutdownOutput.' (create): create `channel,' initialize `impl's native state. (connect): use `connect(SocketAddress, int).' (connect): use `SocketChannelImpl.connect;' initialize `address' and `port.' (bind): use `VMPlainSocketImpl.bind.' (listen): use `VMPlainSocketImpl.listen.' (accept): use `SocketChannelImpl.accept.' (available): use `VMChannel.available.' (close): use `PlainSocketImpl.close.' (sendUrgentData): use `PlainSocketImpl.sendUrgentData.' (getVMChannel, getInetAddress, getLocalPort, getLocalAddress, getPort): new methods. (SocketInputStream.read): use `VMChannel.read.' (SocketInputStream.read): use `SocketChannel.read.' (SocketOutputStream.write): use `VMChannel.write.' (SocketOutputStream.write): use `SocketChannel.write.' * gnu/java/nio/DatagramChannelImpl.java: implement VMChannel. (channel): new field. (init): initialize `channel.' (implCloseSelectableChannel): use `VMChannel.close.' (implConfigureBlocking): use `VMChannel.setBlocking.' (connect): use `VMChannel.connect.' (disconnect): use `VMChannel.disconnect.' (isConnected): use `VMChannel.getPeerAddress.' (write): use `VMChannel.write.' (write): use `VMChannel.writeGathering.' (read): use `VMChannel.read.' (read): use `VMChannel.readScattering.' (receive): use `VMChannel.receive.' (send): use `VMChannel.send.' (getVMChannel): new method. * gnu/java/nio/DatagramChannelSelectionKey.java (getNativeFD): access native FD through VMChannel.State. * gnu/java/nio/FileChannelImpl.java: moved from gnu/java/nio/channels/FileChannelImpl.java. * gnu/java/nio/FileLockImpl.java: fix imports. * gnu/java/nio/KqueueSelectionKeyImpl.java: new file. * gnu/java/nio/KqueueSelectorImpl.java
[cp-patches] FYI: big IO, net, NIO change
OK. Hibbego. I'm checking in my patch that I've been writing about recently. Again, the patch itself is large, so I'll just post a link to it: http://metastatic.org/source/io-nio-final.patch To summarize, this patch: * Implements most non-blocking operations for real -- that is, using native function calls on file descriptors in non-blocking mode. Blocking-IO APIs now defer to the NIO API, in blocking mode. * Refactors our code and the VM interfaces to keep no native state (such as file descriptor integers) in core classes, but instead in VM classes. A number of VM classes have, unfortunately, been modified to support this, but I think in general these changes are for the best. * Implements NetworkInterface using getifaddrs. * Adds a Selector that uses kqueue, the preferred event notification mechanism on OS X. There is more work to do here. In particular, too much code in the core classes knows about file descriptor integers; this too should be moved to the VM classes. Also, an epoll-based selector for Linux would be nice to have. If this breaks anything at all (the Mauve tests I've run, on OS X and Linux, seem to show that this code works well) please complain (fiercely if you must ;-) to me about it. It's a little uncouth to check in such a large patch, sure, but I think this is the good and correct way to implement IO in Java. I've updated NEWS to explain these changes. The change log is also large, but detailed about lots of little changes: 2006-09-16 Casey Marshall [EMAIL PROTECTED] * NEWS: updated. * configure.ac (AC_CHECK_HEADERS): check for `sys/event.h'. (AC_CHECK_FUNCS): add checks for readv, writev, getifaddrs, kqueue, and kevent. (HAVE_INET6): define if IPv6 is supported. * gnu/java/net/PlainDatagramSocketImpl.java (channel): new field. (native_fd): removed. (impl): new field. (init): throw IOException; initialize fields. (finalize): removed. (getNativeFD): removed. (bind): use `PlainSocketImpl.bind.' (create): use `PlainSocketImpl.initSocket.' (disconnect): use `PlainSocketImpl.disconnect.' (getLocalPort): new method. (send): use `VMChannel.send.' (receive): use `VMChannel.receive.' (setOption): use `PlainSocketImpl.setOption.' (getOption): use `PlainSocketImpl.getOption.' (close): use `VMChannel.State.close.' (join): use `PlainSocketImpl.join.' (leave): use `PlainSocketImpl.leave.' (joinGroup, leaveGroup): implemented. * gnu/java/net/PlainSocketImpl.java: make non-final. (native_fd): removed. (impl): new field. (channel): new field. (init): initialize `impl.' (finalize, getNativeFD): removed. (setOption): use `PlainSocketImpl.setOption.' (getOption): use `PlainSocketImpl.getOption.' (shutdownInput): use `PlainSocketImpl.shutdownInput.' (shutdownOutput): use `PlainSocketImpl.shutdownOutput.' (create): create `channel,' initialize `impl's native state. (connect): use `connect(SocketAddress, int).' (connect): use `SocketChannelImpl.connect;' initialize `address' and `port.' (bind): use `VMPlainSocketImpl.bind.' (listen): use `VMPlainSocketImpl.listen.' (accept): use `SocketChannelImpl.accept.' (available): use `VMChannel.available.' (close): use `PlainSocketImpl.close.' (sendUrgentData): use `PlainSocketImpl.sendUrgentData.' (getVMChannel, getInetAddress, getLocalPort, getLocalAddress, getPort): new methods. (SocketInputStream.read): use `VMChannel.read.' (SocketInputStream.read): use `SocketChannel.read.' (SocketOutputStream.write): use `VMChannel.write.' (SocketOutputStream.write): use `SocketChannel.write.' * gnu/java/nio/DatagramChannelImpl.java: implement VMChannel. (channel): new field. (init): initialize `channel.' (implCloseSelectableChannel): use `VMChannel.close.' (implConfigureBlocking): use `VMChannel.setBlocking.' (connect): use `VMChannel.connect.' (disconnect): use `VMChannel.disconnect.' (isConnected): use `VMChannel.getPeerAddress.' (write): use `VMChannel.write.' (write): use `VMChannel.writeGathering.' (read): use `VMChannel.read.' (read): use `VMChannel.readScattering.' (receive): use `VMChannel.receive.' (send): use `VMChannel.send.' (getVMChannel): new method. * gnu/java/nio/DatagramChannelSelectionKey.java (getNativeFD): access native FD through VMChannel.State. * gnu/java/nio/FileChannelImpl.java: moved from gnu/java/nio/channels/FileChannelImpl.java. * gnu/java/nio/FileLockImpl.java: fix imports. * gnu/java/nio/KqueueSelectionKeyImpl.java: new file. * gnu/java/nio/KqueueSelectorImpl.java
Re: [cp-patches] FYI: big IO, net, NIO change
Casey Marshall wrote:
OK. Hibbego.
I'm checking in my patch that I've been writing about recently.
There was a warning about an unused parameter in jcl.c. It didn't get
mentioned on Darwin, but does on Linux. The attached fixes it.
2006-09-17 Casey Marshall [EMAIL PROTECTED]
* native/jni/classpath/jcl.c (JNI_OnLoad): mark `reserved' as
unused.
Committed.
Index: native/jni/classpath/jcl.c
===
RCS file: /cvsroot/classpath/classpath/native/jni/classpath/jcl.c,v
retrieving revision 1.24
diff -u -r1.24 jcl.c
--- native/jni/classpath/jcl.c 17 Sep 2006 07:31:43 - 1.24
+++ native/jni/classpath/jcl.c 17 Sep 2006 19:09:22 -
@@ -51,15 +51,15 @@
/*
* Cached Pointer class info.
*/
-static jclass rawDataClass;
-static jfieldID rawData_fid;
-static jmethodID rawData_mid;
+static jclass rawDataClass = NULL;
+static jfieldID rawData_fid = NULL;
+static jmethodID rawData_mid = NULL;
/*
* JNI OnLoad constructor.
*/
jint
-JNI_OnLoad (JavaVM *vm, void *reserved)
+JNI_OnLoad (JavaVM *vm, void *reserved __attribute__((unused)))
{
JNIEnv *env;
void *envp;
[commit-cp] classpath ChangeLog NEWS configure.ac gnu/java/...
CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Casey Marshall rsdio 06/09/17 07:31:43 Modified files: . : ChangeLog NEWS configure.ac gnu/java/net : PlainDatagramSocketImpl.java PlainSocketImpl.java gnu/java/nio : DatagramChannelImpl.java DatagramChannelSelectionKey.java FileLockImpl.java NIOSocket.java PipeImpl.java SelectionKeyImpl.java SelectorProviderImpl.java ServerSocketChannelImpl.java ServerSocketChannelSelectionKey.java SocketChannelImpl.java SocketChannelSelectionKey.java SocketChannelSelectionKeyImpl.java include: Makefile.am gnu_java_net_VMPlainSocketImpl.h gnu_java_nio_VMChannel.h gnu_java_nio_VMPipe.h java_net_VMNetworkInterface.h java/io: FileDescriptor.java FileInputStream.java FileOutputStream.java RandomAccessFile.java java/net : DatagramSocket.java NetworkInterface.java ServerSocket.java Socket.java native/jni/classpath: jcl.c native/jni/java-lang: java_lang_VMProcess.c native/jni/java-net: gnu_java_net_VMPlainSocketImpl.c java_net_VMNetworkInterface.c native/jni/java-nio: Makefile.am gnu_java_nio_VMChannel.c gnu_java_nio_VMPipe.c native/jni/native-lib: cpnet.c vm/reference/gnu/java/net: VMPlainSocketImpl.java vm/reference/gnu/java/nio: VMChannel.java VMPipe.java vm/reference/java/net: VMNetworkInterface.java vm/reference/java/nio/channels: VMChannels.java Added files: gnu/java/nio : FileChannelImpl.java KqueueSelectionKeyImpl.java KqueueSelectorImpl.java NIOSocketImpl.java VMChannelOwner.java include: gnu_java_nio_FileChannelImpl.h gnu_java_nio_KqueueSelectorImpl.h native/jni/java-nio: gnu_java_nio_KqueueSelectorImpl.c javanio.c javanio.h Removed files: gnu/java/nio/channels: FileChannelImpl.java Log message: 2006-09-16 Casey Marshall [EMAIL PROTECTED] * NEWS: updated. * configure.ac (AC_CHECK_HEADERS): check for `sys/event.h'. (AC_CHECK_FUNCS): add checks for readv, writev, getifaddrs, kqueue, and kevent. (HAVE_INET6): define if IPv6 is supported. * gnu/java/net/PlainDatagramSocketImpl.java (channel): new field. (native_fd): removed. (impl): new field. (init): throw IOException; initialize fields. (finalize): removed. (getNativeFD): removed. (bind): use `PlainSocketImpl.bind.' (create): use `PlainSocketImpl.initSocket.' (disconnect): use `PlainSocketImpl.disconnect.' (getLocalPort): new method. (send): use `VMChannel.send.' (receive): use `VMChannel.receive.' (setOption): use `PlainSocketImpl.setOption.' (getOption): use `PlainSocketImpl.getOption.' (close): use `VMChannel.State.close.' (join): use `PlainSocketImpl.join.' (leave): use `PlainSocketImpl.leave.' (joinGroup, leaveGroup): implemented. * gnu/java/net/PlainSocketImpl.java: make non-final. (native_fd): removed. (impl): new field. (channel): new field. (init): initialize `impl.' (finalize, getNativeFD): removed. (setOption): use `PlainSocketImpl.setOption.' (getOption): use `PlainSocketImpl.getOption.' (shutdownInput): use `PlainSocketImpl.shutdownInput.' (shutdownOutput): use `PlainSocketImpl.shutdownOutput.' (create): create `channel,' initialize `impl's native state. (connect): use `connect(SocketAddress, int).' (connect): use `SocketChannelImpl.connect;' initialize `address' and `port.' (bind): use `VMPlainSocketImpl.bind.' (listen): use `VMPlainSocketImpl.listen.' (accept): use `SocketChannelImpl.accept.' (available): use `VMChannel.available.' (close): use `PlainSocketImpl.close.' (sendUrgentData): use `PlainSocketImpl.sendUrgentData.' (getVMChannel, getInetAddress, getLocalPort, getLocalAddress, getPort): new methods
Re: [cp-patches] updated: IO, net, and NIO
Thomas Fitzsimmons wrote: Casey Marshall wrote: Casey Marshall wrote: http://metastatic.org/source/io-nio.patch http://metastatic.org/source/io-nio2.patch I've updated these again. One of these days I'll take the time to apply these to a clean checkout, and test that. Promise. Or, hey, is this OK to commit yet? I get fewer Mauve failures now, and this may be easier to debug once I've committed it. Yes, this fixes a major problem with java.net.ServerSocket.accept so I think it should go in right away. OK. I'll try to check it in this weekend, unless someone objects before then. I'll check in my patches to the JCL code, and to implement NetworkInterface, too. They both seem to work fine on jamvm and cacao.
Re: [cp-patches] updated: IO, net, and NIO
Thomas Fitzsimmons wrote: OK, the new patches build for me (though I had to add KqueueSelectorImpl lines to include/Makefile.am) but now running rmiregistry under cacao fails like this: $ gdb --args /notnfs/fitzsim/install/classpath-inst/bin/cacao gnu.java.rmi.registry.RegistryImpl GNU gdb Red Hat Linux (6.3.0.0-1.122rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-redhat-linux-gnu...Using host libthread_db library /lib/libthread_db.so.1. (gdb) r Starting program: /notnfs/fitzsim/install/classpath-inst/bin/cacao gnu.java.rmi.registry.RegistryImpl Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0x2d3000 [Thread debugging using libthread_db enabled] [New Thread -1209055568 (LWP 8805)] [New Thread 2132896 (LWP 8808)] [New Thread 1186720 (LWP 8809)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1209055568 (LWP 8805)] 0x00387c3d in GetDirectBufferAddress (env=0x8343038, buf=0x83a0a10) at /home/fitzsim/workspace/cacao/src/native/jni.c:5324 5324return (void *) address-data; (gdb) p address $1 = (gnu_classpath_Pointer32 *) 0x0 (gdb) bt #0 0x00387c3d in GetDirectBufferAddress (env=0x8343038, buf=0x83a0a10) at /home/fitzsim/workspace/cacao/src/native/jni.c:5324 #1 0x0023ee02 in JCL_init_buffer (env=0x8343038, buf=0xbfd00f80, bbuf=0x83a0a10) at /home/fitzsim/workspace/classpath/native/jni/java-nio/gnu_java_nio_VMChannel.c:139 #2 0x0023ff56 in Java_gnu_java_nio_VMChannel_read__ILjava_nio_ByteBuffer_2 (env=0x8343038, o=0x839f098, fd=8, bbuf=0x83a0a10) at /home/fitzsim/workspace/classpath/native/jni/java-nio/gnu_java_nio_VMChannel.c:368 #3 0x00852c02 in ?? () #4 0x08343038 in ?? () #5 0x0839f098 in ?? () #6 0x0008 in ?? () #7 0x083a0a10 in ?? () #8 0x0023ff20 in Java_gnu_java_nio_VMChannel_write__ILjava_nio_ByteBuffer_2 () at /home/fitzsim/workspace/classpath/native/jni/java-nio/gnu_java_nio_VMChannel.c:445 Previous frame inner to this frame (corrupt stack?) (gdb) Have you seen this failure? No, I haven't. Does cacao support GetDirectBufferAddress properly? There may be a bug there.
Re: [cp-patches] updated: IO, net, and NIO
Mark Wielaard wrote: On Wed, 2006-09-13 at 18:01 -0400, Thomas Fitzsimmons wrote: I'm testing these patches to see if they fix the RMI problem I'm having (which may be unrelated): [...] Were you aware of this problem? I think it was introduced by Mark's native layer merge. They were definitely introduced by my merging in the new native-layer branch stuff from Guilhem. Sorry about that. I was secretly hoping Casey's rewrite would automagically fix them. I have not yet tried the patch, but the corresponding Mauve tests (that worked before the merge, but failed after) are: FAIL: org.omg.CORBA.ORB.parallelRunTest FAIL: org.omg.CORBA.ORB.DirectTest FAIL: org.omg.CORBA_2_3.ORB.ValueTypeTest FAIL: org.omg.PortableServer.POAOperations.poa_POA_test FAIL: org.omg.PortableInterceptor.Interceptor.testInterceptors They are all related to socket timeouts. Some of those org.omg tests work for me. I do get two failures, however. I'm suspicious of this broken pipe error: FAIL: org.omg.CORBA.ORB.RequestTest line 134: string [2] -- uncaught exception: org.omg.CORBA.MARSHAL at gnu.CORBA.GIOP.MessageHeader.write(MessageHeader.java:374) at gnu.CORBA.gnuRequest.submit(gnuRequest.java:831) at gnu.CORBA.gnuRequest.p_invoke(gnuRequest.java:940) at gnu.CORBA.gnuRequest.invoke(gnuRequest.java:510) at gnu.testlet.org.omg.CORBA.ORB.RequestTest.testParameters(RequestTest.java:134) at gnu.testlet.org.omg.CORBA.ORB.RequestTest.test(RequestTest.java:90) at RunnerProcess.runtest(RunnerProcess.java:337) at RunnerProcess.runAndReport(RunnerProcess.java:392) at RunnerProcess.main(RunnerProcess.java:219) org.omg.CORBA.MARSHAL: IOException while writing message header Minor: 0 (0). Completed: not completed at gnu.CORBA.Version.write(Version.java:215) at gnu.CORBA.GIOP.MessageHeader.write(MessageHeader.java:367) at gnu.CORBA.gnuRequest.submit(gnuRequest.java:831) at gnu.CORBA.IorDelegate.invoke(IorDelegate.java:184) FAIL: org.omg.PortableServer.POAOperations.poa_POA_test at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:202) line 481: Exc:org.omg.CORBA.MARSHAL: IOException while writing message header Minor: 0 (0). Completed: not completed:java.io.IOException: Broken pipe [1] -- forced fail at gnu.testlet.org.omg.PortableServer.POAOperations.communication.poa_comTesterStub.passCharacters(poa_comTesterStub.java:138) at gnu.testlet.org.omg.PortableServer.POAOperations.poa_POA_test.test_RETAIN_Activation(poa_POA_test.java:109) at gnu.testlet.org.omg.PortableServer.POAOperations.poa_POA_test.test(poa_POA_test.java:467) at RunnerProcess.runtest(RunnerProcess.java:337) at RunnerProcess.runAndReport(RunnerProcess.java:392) at RunnerProcess.main(RunnerProcess.java:219) Caused by: java.io.IOException: Broken pipe at gnu.java.nio.VMChannel.write(Native Method) at gnu.java.nio.VMChannel.write(VMChannel.java:323) at gnu.java.net.PlainSocketImpl$SocketOutputStream.write(PlainSocketImpl.java:567) at java.io.DataOutputStream.write(DataOutputStream.java:115) at gnu.CORBA.Version.write(Version.java:210) ...10 more
Re: [cp-patches] updated: IO, net, and NIO
Casey Marshall wrote: http://metastatic.org/source/io-nio.patch http://metastatic.org/source/io-nio2.patch I've updated these again. One of these days I'll take the time to apply these to a clean checkout, and test that. Promise. Or, hey, is this OK to commit yet? I get fewer Mauve failures now, and this may be easier to debug once I've committed it.
Re: gnu.classpath.VMStackWalker
Andrew Haley wrote:
The current gnu.classpath.VMStackWalker interface is inefficient.
Sun provide:
sun.reflect.reflection.getCallerClass(int depth)
and for the same function we would do
VMStackWalker.getClassContext()[depth];
You see the difference: Classpath's VMStackWalker enumerates the whole
stack, whereas Sun's only has to enumerate a few stack frames.
I would like to add a new method to VMStackWalker that has exactly the
same interface as sun.reflect.reflection.getCallerClass.
This is an obvious reference implementation:
static Class getCallerClass(int depth)
{
Class[] stack = getClassContext();
if (depth stack.length)
return stack[depth];
else
return null;
}
If we had this interface, it would reduce the number of places where
libgcj diverges from classpath, because in gcj we would be able to use
VMStackWalker rather than gcj's internal stacktrace machinery. It
wouldn't work everywhere, but it woud be useful in a number of places.
Looks reasonable to me.
Should the RI throw an exception if depth = stack.length, though?
[cp-patches] updated: IO, net, and NIO
I've updated my patch that updates IO, net, and NIO to better support non-blocking IO, which also includes my kqueue Selector, and the implementation of NetworkInterface. Along with implementing real non-blocking IO, I've rewritten parts of the IO and net code to use the NIO implementation, reducing the amount of code use. I've also tried to make the JNI code as simple as possible, and to abstract out as much of this native code logic into the VM interface classes (IOW, the native logic is private instance data of our VM interface reference implementation). I only get a few Mauve failures with this patch; most of them look like my tree is just out of date (serialization, URL and InetAddress, none of which I've changed here). Mauve may not be testing everything, though, so it's likely that there are bugs lurking here. The patches are big, so I'll just link to them here: http://metastatic.org/source/io-nio.patch http://metastatic.org/source/io-nio2.patch I haven't cleaned everything up, yet, so there are still some obsolete files that aren't removed yet, and I haven't addressed SIGPIPE at all. I've only tested this so far on Darwin/x86, but I'll try this on Linux/x86 too. Comments appreciated! Especially on whether or not this is good enough to commit, or what's lacking. Thanks.
Re: [cp-patches] updated: IO, net, and NIO
Thomas Fitzsimmons wrote: Hi, Casey Marshall wrote: I've updated my patch that updates IO, net, and NIO to better support non-blocking IO, which also includes my kqueue Selector, and the implementation of NetworkInterface. Along with implementing real non-blocking IO, I've rewritten parts of the IO and net code to use the NIO implementation, reducing the amount of code use. I've also tried to make the JNI code as simple as possible, and to abstract out as much of this native code logic into the VM interface classes (IOW, the native logic is private instance data of our VM interface reference implementation). I only get a few Mauve failures with this patch; most of them look like my tree is just out of date (serialization, URL and InetAddress, none of which I've changed here). Mauve may not be testing everything, though, so it's likely that there are bugs lurking here. The patches are big, so I'll just link to them here: http://metastatic.org/source/io-nio.patch http://metastatic.org/source/io-nio2.patch I haven't cleaned everything up, yet, so there are still some obsolete files that aren't removed yet, and I haven't addressed SIGPIPE at all. I've only tested this so far on Darwin/x86, but I'll try this on Linux/x86 too. Comments appreciated! Especially on whether or not this is good enough to commit, or what's lacking. I get these errors after applying io-nio.patch then io-nio2.patch, re-running autogen.sh, and doing a clean build: 2. ERROR in /home/fitzsim/workspace/classpath/gnu/java/nio/channels/FileChannelImpl.java Whoops, yeah, I moved FileChannelImpl.java from gnu/java/nio/channels (it was the only class in that package) to gnu/java/nio; the patch probably doesn't reflect that. I thought I had it marked for delete locally... [...] -- 6. ERROR in /home/fitzsim/workspace/classpath/gnu/java/nio/KqueueSelectorImpl.java (at line 267) protected KqueueSelectionKeyImpl register(AbstractSelectableChannel channel, int interestOps, Object attachment) ^ ^^ The return type is incompatible with AbstractSelector.register(AbstractSelectableChannel, int, Object) Again, oops :-). Eclipse was using 1.5 semantics, I guess, where you can return a derived type instead of the declared type in a overridden method. The return type for that method should be 'SelectionKey.' I'm testing these patches to see if they fix the RMI problem I'm having (which may be unrelated): $ rmiregistry 3456 $ java -Djava.security.policy=/home/fitzsim/jin.patches/wideopen.policy examples.hello.HelloImpl java.net.SocketTimeoutException: Accept operation timed out [...] Were you aware of this problem? I think it was introduced by Mark's native layer merge. I wasn't aware of that problem, no. Since this patch rewrites accept() pretty much from scratch, then yeah, it may work in my version.
Re: [cp-patches] updated: IO, net, and NIO
Thomas Fitzsimmons wrote: Hi, Casey Marshall wrote: I wasn't aware of that problem, no. Since this patch rewrites accept() pretty much from scratch, then yeah, it may work in my version. Two more errors: 5. ERROR in /home/fitzsim/workspace/classpath/gnu/java/nio/FileChannelImpl.java (at line 128) this.ch = VMChannel.getVMChannel(this); The method getVMChannel(FileChannelImpl) is undefined for the type VMChannel -- 6. ERROR in /home/fitzsim/workspace/classpath/gnu/java/nio/FileChannelImpl.java (at line 161) this.ch = VMChannel.getVMChannel(this); The method getVMChannel(FileChannelImpl) is undefined for the type VMChannel ? Those calls don't appear in my local copy, or in the patch. (note, io-nio2.patch added nio/FileChannelImpl.java, but neither patch removed the original) Also, the patches are missing javanio.h. Noted (oops). I've updated the patches to fix these issues. cvs diff seems to refuse to add a removal diff to the patch, though.
Re: [cp-patches] PATCH: fix for JCL_GetRawData
Casey Marshall wrote: This is a better attempt at fixing the JCL_NewRawDataObject and JCL_GetRawData, which initializes the cached class, method, and field variables in JNI_OnLoad. This is potentially problematic, I suppose, because the jcl.lo object is linked directly to a number of Classpath's JNI libraries, which I suppose would mean that any such library couldn't have its own JNI_OnLoad. None of them do now, however (this sounds like it may be wrong, anyway: the JNI invocation interface docs seem to indicate that you need to have this function in your JNI library, which returns the JNI version you want to use, because otherwise the VM will assume you will be using the 1.1 interface; IOW we're using it wrong if we use JNI functions beyond 1.1. This sounds silly, though, and it works regardless). Comments on whether or not this will work are appreciated. 2006-09-09 Casey Marshall [EMAIL PROTECTED] * native/jni/classpath/jcl.c (JNI_OnLoad): new function. (JCL_NewRawDataObject): use pre-initialized Pointer variables. (JCL_GetRawData): likewise. Tested on Darwin/x86/jamvm, Linux/x86/cacao and Linux/x86/jamvm. Does this look OK to commit?
Re: [cp-patches] RFC: implement NetworkInterface
Here's a revised patch that uses getifaddrs. Works on Darwin with jamvm,
I have not yet tested Linux.
This still contains the same fix for jcl.c. I'll try to come up with a
better solution that fixes the issue, but for now, if you want to try it
on JamVM, you'll need this fix.
? native/jni/java-net/netif.c
? native/jni/java-net/netif.h
Index: configure.ac
===
RCS file: /cvsroot/classpath/classpath/configure.ac,v
retrieving revision 1.181
diff -u -r1.181 configure.ac
--- configure.ac31 Aug 2006 19:56:03 - 1.181
+++ configure.ac9 Sep 2006 19:01:13 -
@@ -373,12 +373,19 @@
fcntl \
mmap munmap mincore msync madvise getpagesize sysconf \
lstat readlink \
- ])
+ getifaddrs])
LIBMAGIC=
AC_CHECK_LIB(magic, magic_open, LIBMAGIC=-lmagic)
AC_SUBST(LIBMAGIC)
+ AC_MSG_CHECKING([whether struct sockaddr_in6 is in netinet/in.h])
+ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include netinet/in.h]], [[struct
sockaddr_in6 addr6;]])],
+[AC_DEFINE(HAVE_INET6, 1,
+ [Define if inet6 structures are defined in netinet/in.h.])
+ AC_MSG_RESULT(yes)],
+[AC_MSG_RESULT(no)])
+
AC_HEADER_TIME
AC_STRUCT_TM
AC_STRUCT_TIMEZONE
Index: include/java_net_VMNetworkInterface.h
===
RCS file: /cvsroot/classpath/classpath/include/java_net_VMNetworkInterface.h,v
retrieving revision 1.1
diff -u -r1.1 java_net_VMNetworkInterface.h
--- include/java_net_VMNetworkInterface.h 11 Apr 2005 18:58:38 -
1.1
+++ include/java_net_VMNetworkInterface.h 9 Sep 2006 19:01:13 -
@@ -1,19 +1,29 @@
/* DO NOT EDIT THIS FILE - it is machine generated */
-
-#ifndef __java_net_VMNetworkInterface__
-#define __java_net_VMNetworkInterface__
-
#include jni.h
+/* Header for class java_net_VMNetworkInterface */
+#ifndef _Included_java_net_VMNetworkInterface
+#define _Included_java_net_VMNetworkInterface
#ifdef __cplusplus
-extern C
-{
+extern C {
#endif
-
-JNIEXPORT jobject JNICALL Java_java_net_VMNetworkInterface_getInterfaces
(JNIEnv *env, jclass);
+/*
+ * Class: java_net_VMNetworkInterface
+ * Method:initIds
+ * Signature: ()V
+ */
+JNIEXPORT void JNICALL Java_java_net_VMNetworkInterface_initIds
+ (JNIEnv *, jclass);
+
+/*
+ * Class: java_net_VMNetworkInterface
+ * Method:getVMInterfaces
+ * Signature: ()[Ljava/net/VMNetworkInterface;
+ */
+JNIEXPORT jobjectArray JNICALL Java_java_net_VMNetworkInterface_getVMInterfaces
+ (JNIEnv *, jclass);
#ifdef __cplusplus
}
#endif
-
-#endif /* __java_net_VMNetworkInterface__ */
+#endif
Index: java/net/NetworkInterface.java
===
RCS file: /cvsroot/classpath/classpath/java/net/NetworkInterface.java,v
retrieving revision 1.18
diff -u -r1.18 NetworkInterface.java
--- java/net/NetworkInterface.java 29 Aug 2006 08:25:15 - 1.18
+++ java/net/NetworkInterface.java 9 Sep 2006 19:01:14 -
@@ -38,6 +38,8 @@
package java.net;
+import gnu.classpath.SystemProperties;
+
import java.util.Collection;
import java.util.Collections;
import java.util.Enumeration;
@@ -58,25 +60,13 @@
*/
public final class NetworkInterface
{
- private String name;
- private Vector inetAddresses;
-
- NetworkInterface(String name, InetAddress address)
- {
-this.name = name;
-this.inetAddresses = new Vector(1, 1);
-this.inetAddresses.add(address);
- }
+ private final VMNetworkInterface netif;
- NetworkInterface(String name, InetAddress[] addresses)
+ private NetworkInterface(VMNetworkInterface netif)
{
-this.name = name;
-this.inetAddresses = new Vector(addresses.length, 1);
-
-for (int i = 0; i addresses.length; i++)
- this.inetAddresses.add(addresses[i]);
+this.netif = netif;
}
-
+
/**
* Returns the name of the network interface
*
@@ -84,7 +74,7 @@
*/
public String getName()
{
-return name;
+return netif.name;
}
/**
@@ -100,6 +90,7 @@
public Enumeration getInetAddresses()
{
SecurityManager s = System.getSecurityManager();
+Vector inetAddresses = new Vector(netif.addresses);
if (s == null)
return inetAddresses.elements();
@@ -131,7 +122,7 @@
*/
public String getDisplayName()
{
-return name;
+return netif.name;
}
/**
@@ -148,15 +139,14 @@
public static NetworkInterface getByName(String name)
throws SocketException
{
-for (Enumeration e = getNetworkInterfaces(); e.hasMoreElements();)
+if (name == null)
+ throw new NullPointerException();
+VMNetworkInterface[] netifs = VMNetworkInterface.getVMInterfaces();
+for (int i = 0; i netifs.length; i++)
{
- NetworkInterface tmp = (NetworkInterface) e.nextElement();
-
-
[cp-patches] PATCH: fix for JCL_GetRawData
This is a better attempt at fixing the JCL_NewRawDataObject and
JCL_GetRawData, which initializes the cached class, method, and field
variables in JNI_OnLoad.
This is potentially problematic, I suppose, because the jcl.lo object is
linked directly to a number of Classpath's JNI libraries, which I
suppose would mean that any such library couldn't have its own
JNI_OnLoad. None of them do now, however (this sounds like it may be
wrong, anyway: the JNI invocation interface docs seem to indicate that
you need to have this function in your JNI library, which returns the
JNI version you want to use, because otherwise the VM will assume you
will be using the 1.1 interface; IOW we're using it wrong if we use JNI
functions beyond 1.1. This sounds silly, though, and it works regardless).
Comments on whether or not this will work are appreciated.
2006-09-09 Casey Marshall [EMAIL PROTECTED]
* native/jni/classpath/jcl.c (JNI_OnLoad): new function.
(JCL_NewRawDataObject): use pre-initialized Pointer variables.
(JCL_GetRawData): likewise.
Thanks.
? native/jni/classpath/jcl_nstate.c
? native/jni/classpath/jcl_pointer.c
? native/jni/classpath/jcl_pointer.h
Index: native/jni/classpath/jcl.c
===
RCS file: /cvsroot/classpath/classpath/native/jni/classpath/jcl.c,v
retrieving revision 1.23
diff -u -r1.23 jcl.c
--- native/jni/classpath/jcl.c 3 Apr 2006 14:03:12 - 1.23
+++ native/jni/classpath/jcl.c 10 Sep 2006 03:46:35 -
@@ -48,6 +48,63 @@
#endif
#endif
+/*
+ * Cached Pointer class info.
+ */
+static jclass rawDataClass;
+static jfieldID rawData_fid;
+static jmethodID rawData_mid;
+
+/*
+ * JNI OnLoad constructor.
+ */
+jint
+JNI_OnLoad (JavaVM *vm, void *reserved)
+{
+ JNIEnv *env;
+
+ if ((*vm)-GetEnv (vm, env, JNI_VERSION_1_4) != JNI_OK)
+{
+ return JNI_VERSION_1_4;
+}
+#if SIZEOF_VOID_P == 8
+ rawDataClass = (*env)-FindClass (env, gnu/classpath/Pointer64);
+ if (rawDataClass != NULL)
+{
+ jclass tmp = rawDataClass;
+ rawDataClass = (*env)-NewGlobalRef (env, rawDataClass);
+ (*env)-DeleteGlobalRef (env, tmp);
+}
+
+ if (rawDataClass != NULL)
+{
+ rawData_fid = (*env)-GetFieldID (env, rawDataClass, data, J);
+ rawData_mid = (*env)-GetMethodID (env, rawDataClass, init, (J)V);
+}
+#else
+#if SIZEOF_VOID_P == 4
+ rawDataClass = (*env)-FindClass (env, gnu/classpath/Pointer32);
+ if (rawDataClass != NULL)
+{
+ jclass tmp = rawDataClass;
+ rawDataClass = (*env)-NewGlobalRef (env, rawDataClass);
+ (*env)-DeleteGlobalRef (env, tmp);
+}
+
+ if (rawDataClass != NULL)
+{
+ rawData_fid = (*env)-GetFieldID (env, rawDataClass, data, I);
+ rawData_mid = (*env)-GetMethodID (env, rawDataClass, init, (I)V);
+}
+#else
+#error Pointer size is not supported.
+#endif /* SIZEOF_VOID_P == 4 */
+#endif /* SIZEOF_VOID_P == 8 */
+
+ return JNI_VERSION_1_4;
+}
+
+
JNIEXPORT void JNICALL
JCL_ThrowException (JNIEnv * env, const char *className, const char *errMsg)
{
@@ -183,78 +240,17 @@
/*
- * Build a Pointer object. The function caches the class type
+ * Build a Pointer object.
*/
-static jclass rawDataClass;
-static jfieldID rawData_fid;
-static jmethodID rawData_mid;
-
JNIEXPORT jobject JNICALL
JCL_NewRawDataObject (JNIEnv * env, void *data)
{
- if (rawDataClass == NULL)
+ if (rawDataClass == NULL || rawData_mid == NULL)
{
- jclass tmp;
-#if SIZEOF_VOID_P == 8
- rawDataClass = (*env)-FindClass (env, gnu/classpath/Pointer64);
- if (rawDataClass == NULL)
- {
- JCL_ThrowException (env, java/lang/InternalError,
- unable to find internal class);
- return NULL;
- }
-
- rawData_mid = (*env)-GetMethodID (env, rawDataClass, init, (J)V);
- if (rawData_mid == NULL)
- {
- JCL_ThrowException (env, java/lang/InternalError,
- unable to find internal constructor);
- return NULL;
- }
-
- rawData_fid = (*env)-GetFieldID (env, rawDataClass, data, J);
- if (rawData_fid == NULL)
- {
- JCL_ThrowException (env, java/lang/InternalError,
- unable to find internal field);
- return NULL;
- }
-#else
- rawDataClass = (*env)-FindClass (env, gnu/classpath/Pointer32);
- if (rawDataClass == NULL)
- {
- JCL_ThrowException (env, java/lang/InternalError,
- unable to find internal class);
- return NULL;
- }
-
- rawData_mid = (*env)-GetMethodID (env, rawDataClass, init, (I)V);
- if (rawData_mid == NULL)
- {
- JCL_ThrowException (env, java/lang/InternalError,
- unable to find internal constructor);
- return NULL;
- }
-
- rawData_fid = (*env)-GetFieldID (env, rawDataClass, data, I);
- if (rawData_fid == NULL
