[SOLVED] JacORB marshalling problem with device running on ARM

# 7 years ago
nleclercq	Hi all, I have a LabVIEW device server running on a NI-cRIO ARM v7 platform. From a binary point of view, this device is nothing but a cross compiled C++ device. So far, so good, nothing special, this is supposed to work properly. But, when I try to open Jive to start to play with the embedded device I get an error telling me there's a marshalling problem related to a boolean value (see attached picture for the exact error message). The problem seems to be located in JacORB cause it disappears if I use another client (I tried with Igor pro and it works properly). Is this a known problem? Edited 7 years ago Attachments:

# 7 years ago

Hi all,

I have a LabVIEW device server running on a NI-cRIO ARM v7 platform. From a binary point of view, this device is nothing but a cross compiled C++ device. So far, so good, nothing special, this is supposed to work properly. But, when I try to open Jive to start to play with the embedded device I get an error telling me there's a marshalling problem related to a boolean value (see attached picture for the exact error message).

The problem seems to be located in JacORB cause it disappears if I use another client (I tried with Igor pro and it works properly).

Is this a known problem?

Edited 7 years ago

# 7 years ago
Pascal	Hi Nico Which release of JTango are you using ? Because it seems like a bug fixed several month ago. Pascal

# 7 years ago
nleclercq	Hey Pascal, I'm using JTango 9.0.7. N.

# 7 years ago
Andy	Hi Nico, I have used jive with device servers running on ARM platform like Raspberry PI. I am not sure I have used booleans. What is the exact ARM architecture and options to the compiler. It would be useful to test it on a similar arm hardware here e.g. zynq. Do other data types work e.g. integers + doubles? Can you import the device from jive? Cheers Andy

# 7 years ago
nleclercq	Hi Andy, As far as I remember properly, I didn't specify any particular (i.e. tricky) compiler option while compiling Tango. The target platform is a NI Compact RIO ARMv7. As any developer trying to cross compile omniORB, I had to face its bootstrapped nature but nothing else. The device I'm testing is a LabVIEW implementation of the TangTest device. It owns a command and an attribute for every single data type and format supported by Tango (except Pipe and DevEncoded). The problem I'm reporting only occurs with a Java client (Jive in this case). Using a C++ client, such as the Igor Pro Binding, everything works properly. I can import the device, execute any command or read/write any attribute. The data is properly displayed and has the expected value (i.e. there's no endianness problem). According to what I observe, the problem seems to be located in the JacORB layer. As you can see on the attached screenshot (see original post), the problem occurs while Jive is trying to build the attribute list of the device (in DeviceProxy.get_attribute_config_ex). Googling the error message, it seems related to an unexpected boolean value in the returned data structure. In short, the ORB implementation decodes a boolean value and expect 0 or 1 in 8 bits integer (byte) but finds something different and raises an exception. `public class CDRInputStream extends org.omg.CORBA.portable.InputStream { … public final boolean read_boolean() { index++; byte bb = buffer[pos++]; if( bb == 1 ) return true; else if ( bb == 0 ) return false; else throw new Error("Unexpected boolean value: " + bb + " pos: " + pos + " index: " + index); } … }` The buffer index 'pos' is either wrong on client side or the boolean value is not properly set on server side. Cheers, N Edited 7 years ago

# 7 years ago

nleclercq

Hi Andy,

As far as I remember properly, I didn't specify any particular (i.e. tricky) compiler option while compiling Tango. The target platform is a NI Compact RIO ARMv7. As any developer trying to cross compile omniORB, I had to face its bootstrapped nature but nothing else. The device I'm testing is a LabVIEW implementation of the TangTest device. It owns a command and an attribute for every single data type and format supported by Tango (except Pipe and DevEncoded). The problem I'm reporting only occurs with a Java client (Jive in this case). Using a C++ client, such as the Igor Pro Binding, everything works properly. I can import the device, execute any command or read/write any attribute. The data is properly displayed and has the expected value (i.e. there's no endianness problem). According to what I observe, the problem seems to be located in the JacORB layer.

As you can see on the attached screenshot (see original post), the problem occurs while Jive is trying to build the attribute list of the device (in DeviceProxy.get_attribute_config_ex). Googling the error message, it seems related to an unexpected boolean value in the returned data structure. In short, the ORB implementation decodes a boolean value and expect 0 or 1 in 8 bits integer (byte) but finds something different and raises an exception.

   
public class CDRInputStream extends org.omg.CORBA.portable.InputStream
{
    …
    public final boolean read_boolean()
    {
	index++;
	byte bb = buffer[pos++];

	if( bb == 1 )
	    return true;
	else if ( bb == 0 )
	    return false;
	else
	    throw new Error("Unexpected boolean value: " + bb 
			    + " pos: " + pos + " index: " + index);
    }
    …
}

The buffer index 'pos' is either wrong on client side or the boolean value is not properly set on server side.

Cheers,
N

Edited 7 years ago

# 7 years ago
Pascal	9.0.7 is latest one. The fixed bug I was talking about was on event management on a server whit classes using 2 different TANGO releases. I suppose, this is not your case.

# 7 years ago
nleclercq	Thanks Pascal. Unfortunately it's not my use case.

# 7 years ago
nleclercq	Thanks to Gwen, our local Java guru, the problem is fixed. The solution is to add the following option to the java command line: `-Djacorb.interop.lax_boolean_encoding=true` This tells JacORB to interpret any positive value as true and 0 as false. BTW, this fix also validate the LabVIEW device servers on the NI cRIO platform. PS: Please, don't ask me why omniORB for ARM doesn't behave the same as for x86 (or x64) Edited 7 years ago

# 7 years ago

nleclercq

Thanks to Gwen, our local Java guru, the problem is fixed.

The solution is to add the following option to the java command line:

-Djacorb.interop.lax_boolean_encoding=true

This tells JacORB to interpret any positive value as true and 0 as false.

BTW, this fix also validate the LabVIEW device servers on the NI cRIO platform.

PS: Please, don't ask me why omniORB for ARM doesn't behave the same as for x86 (or x64) smile

Edited 7 years ago