[libvirt] Release of libvirt-java-0.2.0
Okay I made a new release with the API renaming changes we discussed previously. It is available at the usual place: ftp://libvirt.org/libvirt/java/ I also built it for Fedora-9, it should be available for testing there soon too. There is still a few issues, for example I get an out of bound exception error when running the test.java, looks like a pointer/integer conversion error when using the authentification callbacks (I realize i may have left a couple of debug statement in the JNI C file there). In general I'm not sure the jlong VDP cast trick will always work, it looks a bit unsafe but that's an implementation detail it should not affect the API. I tried to incorporate some solaris fixes from John Levon, but i can't garantee it's all fixed (well not the warnings due to the VDP cast) So this is a good version for testing, feedback, patches and expertise much welcome, as I'm sort of a Java newbie ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
I've attached the patch to fix the refactored ConnectAuth jni code. ("javap -private -s" is your friend when doing JNI stuff) I had to do a "cp README README.in" in the cvs downloaded code, bacuase autogen.sh refused to run otherwise. Maybe it's missing from CVS? I am still targeting to add the full storage functionality in early August, when I'm back from vacation. Thanks for all the refactoring work. regards István Daniel Veillard wrote:
Okay I made a new release with the API renaming changes we discussed previously. It is available at the usual place: ftp://libvirt.org/libvirt/java/
I also built it for Fedora-9, it should be available for testing there soon too. There is still a few issues, for example I get an out of bound exception error when running the test.java, looks like a pointer/integer conversion error when using the authentification callbacks (I realize i may have left a couple of debug statement in the JNI C file there). In general I'm not sure the jlong VDP cast trick will always work, it looks a bit unsafe but that's an implementation detail it should not affect the API. I tried to incorporate some solaris fixes from John Levon, but i can't garantee it's all fixed (well not the warnings due to the VDP cast)
So this is a good version for testing, feedback, patches and expertise much welcome, as I'm sort of a Java newbie !
Daniel
? README.in ? src/jni/org_libvirt_Connect.h ? src/jni/org_libvirt_Domain.h ? src/jni/org_libvirt_Domain_CreateFlags.h ? src/jni/org_libvirt_Domain_MigrateFlags.h ? src/jni/org_libvirt_Domain_XMLFlags.h ? src/jni/org_libvirt_Network.h Index: src/jni/ConnectAuthCallbackBridge.c =================================================================== RCS file: /data/cvs/libvirt-java/src/jni/ConnectAuthCallbackBridge.c,v retrieving revision 1.1 diff -u -p -r1.1 ConnectAuthCallbackBridge.c --- src/jni/ConnectAuthCallbackBridge.c 18 Jul 2008 14:37:21 -0000 1.1 +++ src/jni/ConnectAuthCallbackBridge.c 20 Jul 2008 10:21:15 -0000 @@ -15,7 +15,7 @@ int ConnectAuthCallbackBridge(virConnect jmethodID j_auth_cb_id=(*env)->GetMethodID(env, (*env)->GetObjectClass(env, j_auth), "callback", "([Lorg/libvirt/ConnectAuth$Credential;)I"); jclass j_cred_cls = (*env)->FindClass(env, "org/libvirt/ConnectAuth$Credential"); - jmethodID j_cred_constructor = (*env)->GetMethodID(env, j_cred_cls, "<init>", "(ILjava/lang/String;Ljava/lang/String;Ljava/lang/String;)V"); + jmethodID j_cred_constructor = (*env)->GetMethodID(env, j_cred_cls, "<init>", "(Lorg/libvirt/ConnectAuth;ILjava/lang/String;Ljava/lang/String;Ljava/lang/String;)V"); jfieldID j_cred_result_id = (*env)->GetFieldID(env, j_cred_cls, "result", "Ljava/lang/String;"); jobjectArray j_credArray = (*env)->NewObjectArray(env, ncred, j_cred_cls, NULL); @@ -27,6 +27,7 @@ int ConnectAuthCallbackBridge(virConnect j_cred=(*env)->NewObject(env, j_cred_cls, j_cred_constructor, + j_auth, cred[c].type, (*env)->NewStringUTF(env, cred[c].prompt), (*env)->NewStringUTF(env, cred[c].challenge),
On Sun, Jul 20, 2008 at 12:32:41PM +0200, Tóth István wrote:
I've attached the patch to fix the refactored ConnectAuth jni code. ("javap -private -s" is your friend when doing JNI stuff)
Argh, well I went with the full GDB thing, which helped find some of the problems but not that one specifically. Patch applied, but I'm still seeing an error: wei:~/libvirt-java/src -> java -version java version "1.6.0" OpenJDK Runtime Environment (build 1.6.0-b09) OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode) wei:~/libvirt-java/src -> java -classpath .:/usr/share/java/libvirt-0.2.0.jar test In 1openAuth FindClass done Array copied calling virConnectOpenAuth Got NULL Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 1964848024 at org.libvirt.Connect._openAuth(Native Method) at org.libvirt.Connect.<init>(Connect.java:62) at test.main(test.java:26) exception caught:org.libvirt.LibvirtException: ø(1Ú level:null code:null domain:VIR_FROM_NONE hasConn:false hasDom:false hasNet:false message:ø(1Ú str1:Ш¢ str2:3 uÚ str3:éGÿÿÿ int1:2160961 int2:0 virNodeInfo.model:i686 With the debugging stderr calls still left. it seems virConnectOpenAuth() does not work, and it seems something happens within the callback from native to the Java authentication routine. Also seems the exception wrappers don't properly zeroe some of the strings which need some investigation too. Would that be a JVM or 64bits specific issue ? 1964848024 is suspiciously large and 0x751d3398 could well be a valid pointed, but casted to the wrong place.
I had to do a "cp README README.in" in the cvs downloaded code, bacuase autogen.sh refused to run otherwise. Maybe it's missing from CVS?
Oops, yes :-) wei:~/libvirt-java -> cvs -z9 add README.in cvs add: scheduling file `README.in' for addition cvs add: use 'cvs commit' to add this file permanently wei:~/libvirt-java -> cvs -z9 commit -m "Missing new file" README.in RCS file: /data/cvs/libvirt-java/README.in,v done Checking in README.in; /data/cvs/libvirt-java/README.in,v <-- README.in initial revision: 1.1 done wei:~/libvirt-java -> cvs -z9 tag LIBVIRT_JAVA_0_2_0 README.in T README.in wei:~/libvirt-java ->
I am still targeting to add the full storage functionality in early August, when I'm back from vacation.
Heh, enjoy your vacations, and thanks for the quick feedback !
Thanks for all the refactoring work.
Well it made me learn more about the code :-) Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Daniel Veillard wrote:
On Sun, Jul 20, 2008 at 12:32:41PM +0200, Tóth István wrote:
I've attached the patch to fix the refactored ConnectAuth jni code. ("javap -private -s" is your friend when doing JNI stuff)
Argh, well I went with the full GDB thing, which helped find some of the problems but not that one specifically. Patch applied, but I'm still seeing an error:
wei:~/libvirt-java/src -> java -version java version "1.6.0" OpenJDK Runtime Environment (build 1.6.0-b09) OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode) wei:~/libvirt-java/src -> java -classpath .:/usr/share/java/libvirt-0.2.0.jar test In 1openAuth FindClass done Array copied calling virConnectOpenAuth Got NULL Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 1964848024 at org.libvirt.Connect._openAuth(Native Method) at org.libvirt.Connect.<init>(Connect.java:62) at test.main(test.java:26) exception caught:org.libvirt.LibvirtException: ø(1Ú level:null code:null domain:VIR_FROM_NONE hasConn:false hasDom:false hasNet:false message:ø(1Ú str1:Ш¢ str2:3 uÚ str3:éGÿÿÿ int1:2160961 int2:0
virNodeInfo.model:i686
With the debugging stderr calls still left. it seems virConnectOpenAuth() does not work, and it seems something happens within the callback from native to the Java authentication routine. Also seems the exception wrappers don't properly zeroe some of the strings which need some investigation too. Would that be a JVM or 64bits specific issue ? 1964848024 is suspiciously large and 0x751d3398 could well be a valid pointed, but casted to the wrong place.
Strange. I've tested the patch on vanilla F9 64 bit, and it run through without any problems. Must be a problem in the error path (you probably do not have the plain tcp connection mode enabled, that I'm using for testing) I'll try to fix that and send a patch before I leave.
I had to do a "cp README README.in" in the cvs downloaded code, bacuase autogen.sh refused to run otherwise. Maybe it's missing from CVS?
Oops, yes :-)
wei:~/libvirt-java -> cvs -z9 add README.in cvs add: scheduling file `README.in' for addition cvs add: use 'cvs commit' to add this file permanently wei:~/libvirt-java -> cvs -z9 commit -m "Missing new file" README.in RCS file: /data/cvs/libvirt-java/README.in,v done Checking in README.in; /data/cvs/libvirt-java/README.in,v <-- README.in initial revision: 1.1 done wei:~/libvirt-java -> cvs -z9 tag LIBVIRT_JAVA_0_2_0 README.in T README.in wei:~/libvirt-java ->
I am still targeting to add the full storage functionality in early August, when I'm back from vacation.
Heh, enjoy your vacations, and thanks for the quick feedback !
Thanks for all the refactoring work.
Well it made me learn more about the code :-)
Daniel
I've finally hunted down the problem. It stems from the way we (I) handle errors, and is not openAuth specific, it just triggered here. When the virConnectOpen* function encounters an error, it calls the error handler we set in the initializer, which in turn handles the error, and sets a java exception, but DOES NOT RETURN to java land. Next, we try to get the error, which seems to have been cleared after calling the handler. (The deleted code was plain broken anyway, because the error struct is allocated by the virCopyLastError, not the caller), Then we call our error handler function with the uninitialized junk error object, which results in interesting errors. The solution is quite simple, we simply need to return if we are unsuccessful (get NULL vc), and the previously set exception is magically thrown. Generally, we should be much more careful with handling errors and exceptions, but 1.0 is a long way. :-) regards István Daniel Veillard wrote:
On Sun, Jul 20, 2008 at 12:32:41PM +0200, Tóth István wrote:
I've attached the patch to fix the refactored ConnectAuth jni code. ("javap -private -s" is your friend when doing JNI stuff)
Argh, well I went with the full GDB thing, which helped find some of the problems but not that one specifically. Patch applied, but I'm still seeing an error:
wei:~/libvirt-java/src -> java -version java version "1.6.0" OpenJDK Runtime Environment (build 1.6.0-b09) OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode) wei:~/libvirt-java/src -> java -classpath .:/usr/share/java/libvirt-0.2.0.jar test In 1openAuth FindClass done Array copied calling virConnectOpenAuth Got NULL Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 1964848024 at org.libvirt.Connect._openAuth(Native Method) at org.libvirt.Connect.<init>(Connect.java:62) at test.main(test.java:26) exception caught:org.libvirt.LibvirtException: ø(1Ú level:null code:null domain:VIR_FROM_NONE hasConn:false hasDom:false hasNet:false message:ø(1Ú str1:Ш¢ str2:3 uÚ str3:éGÿÿÿ int1:2160961 int2:0
virNodeInfo.model:i686
With the debugging stderr calls still left. it seems virConnectOpenAuth() does not work, and it seems something happens within the callback from native to the Java authentication routine. Also seems the exception wrappers don't properly zeroe some of the strings which need some investigation too. Would that be a JVM or 64bits specific issue ? 1964848024 is suspiciously large and 0x751d3398 could well be a valid pointed, but casted to the wrong place.
I had to do a "cp README README.in" in the cvs downloaded code, bacuase autogen.sh refused to run otherwise. Maybe it's missing from CVS?
Oops, yes :-)
wei:~/libvirt-java -> cvs -z9 add README.in cvs add: scheduling file `README.in' for addition cvs add: use 'cvs commit' to add this file permanently wei:~/libvirt-java -> cvs -z9 commit -m "Missing new file" README.in RCS file: /data/cvs/libvirt-java/README.in,v done Checking in README.in; /data/cvs/libvirt-java/README.in,v <-- README.in initial revision: 1.1 done wei:~/libvirt-java -> cvs -z9 tag LIBVIRT_JAVA_0_2_0 README.in T README.in wei:~/libvirt-java ->
I am still targeting to add the full storage functionality in early August, when I'm back from vacation.
Heh, enjoy your vacations, and thanks for the quick feedback !
Thanks for all the refactoring work.
Well it made me learn more about the code :-)
Daniel
? .project ? README.in ? src/jni/org_libvirt_Connect.h ? src/jni/org_libvirt_Domain.h ? src/jni/org_libvirt_Domain_CreateFlags.h ? src/jni/org_libvirt_Domain_MigrateFlags.h ? src/jni/org_libvirt_Domain_XMLFlags.h ? src/jni/org_libvirt_Network.h Index: src/jni/org_libvirt_Connect.c =================================================================== RCS file: /data/cvs/libvirt-java/src/jni/org_libvirt_Connect.c,v retrieving revision 1.1 diff -u -p -r1.1 org_libvirt_Connect.c --- src/jni/org_libvirt_Connect.c 18 Jul 2008 14:37:21 -0000 1.1 +++ src/jni/org_libvirt_Connect.c 21 Jul 2008 18:48:22 -0000 @@ -149,14 +149,13 @@ JNIEXPORT jlong JNICALL Java_org_libvirt (JNIEnv *env, jobject obj, jstring uri){ virConnectPtr vc; - virError error; //Initialize the libvirt VirtConn Object vc=virConnectOpen((*env)->GetStringUTFChars(env, uri, NULL)); if(vc==NULL){ - virCopyLastError(&error); - virErrorHandler(env, &error); - return (jlong)NULL; + //We have a pending java exception, let's return + assert((*env)->ExceptionOccurred(env)); + return NULL; } //Initialized the error handler for this connection @@ -169,14 +168,13 @@ JNIEXPORT jlong JNICALL Java_org_libvirt (JNIEnv *env, jobject obj, jstring uri){ virConnectPtr vc; - virError error; //Initialize the libvirt VirtConn Object vc=virConnectOpenReadOnly((*env)->GetStringUTFChars(env, uri, NULL)); if(vc==NULL){ - virCopyLastError(&error); - virErrorHandler(env, &error); - return (jlong)NULL; + //We have a pending java exception, let's return + assert((*env)->ExceptionOccurred(env)); + return NULL; } //Initialized the error handler for this connection @@ -237,10 +235,9 @@ fprintf(stderr, "calling virConnectOpenA if(vc==NULL){ fprintf(stderr, "Got NULL\n"); - - virCopyLastError(&error); - virErrorHandler(env, &error); - return (jlong)NULL; + //We have a pending java exception, let's return + assert((*env)->ExceptionOccurred(env)); + return NULL; } //Initialize the error handler for this connection
On Mon, Jul 21, 2008 at 09:12:51PM +0200, Tóth István wrote:
I've finally hunted down the problem.
haha :-)
It stems from the way we (I) handle errors, and is not openAuth specific, it just triggered here.
When the virConnectOpen* function encounters an error, it calls the error handler we set in the initializer, which in turn handles the error, and sets a java exception, but DOES NOT RETURN to java land.
okay
Next, we try to get the error, which seems to have been cleared after calling the handler. (The deleted code was plain broken anyway, because the error struct is allocated by the virCopyLastError, not the caller), Then we call our error handler function with the uninitialized junk error object, which results in interesting errors.
oh, right copying over uninitialized data
The solution is quite simple, we simply need to return if we are unsuccessful (get NULL vc), and the previously set exception is magically thrown.
Okay i see the patch, and applying it makes things work as expected: wei:~/libvirt-java/src -> java -classpath .:/usr/share/java/libvirt-0.2.0.jar test exception caught:org.libvirt.LibvirtException: Connection refused level:VIR_ERR_ERROR code:VIR_ERR_SYSTEM_ERROR domain:VIR_FROM_REMOTE hasConn:false hasDom:false hasNet:false message:Connection refused str1:%s str2:Connection refused str3:null int1:0 int2:0 virNodeInfo.model:i686 .... Now I have to understand why test+tcp URL are not accepted but it's not a java binding issue, oh and find the double free you reported yesterday !
Generally, we should be much more careful with handling errors and exceptions, but 1.0 is a long way. :-)
I'm commiting the fix, I just re-added the cast to jlong as we got a warning otherwise, some of those jlong/pointer/int casts are fishy but as you say 1.0 is a long way :-) in the meantime, enjoy your vacations ! thanks again, Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
participants (2)
-
Daniel Veillard -
Tóth István