[libvirt] Re: Release of libvirt-java-0.2.0

[Tóth István]

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
>
>   

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: connect.patch
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20080721/d500bfbb/attachment-0001.ksh>