#82 Issue with Deserialzers - Alignment issue


Deserialising does not work properly in some cases.
Consider the following example :- The idl looks like this -> idlcall (inout UInt32 num, out sequenceUInt64 A, out sequenceUInt64 long B, out sequenceString C). Consider now that the response stream starts at 24 after removing GIOP headers etc. The UInt32 which is long value will be aligned on 4 byte boundary. So it will be read from 24. The next thing to be read will be length of the UInt64 (long long) sequence. The length is unsigned long and aligned on 4 byte boundary. Assume that both sequences of UInt64 (A,B) have zero elements. So their lenghts will be read from positions 28, 32. The next element to be read is the sequence of strings. First the length has to be read and then the elements. The length is again a unsigned long and should be read from position 36. But the current iiop.net code wrongly aligns it on a 8 byte boundary. Thus the reading happens from position 40 and not 36. This needs to be corrected. (Have done the corrections and tested it too. Works fine)


  • harsh patki

    harsh patki - 2008-11-29

    This issue is identical to 1801185

  • harsh patki

    harsh patki - 2008-11-29

    All methods in class 'CdrEndianDepInputStreamOp' that handle deserializing of arrays need to do conditional aligment. The Aligment should be attempted only if the length of the array is non-zero. For Example :-

    public void ReadLongLongArray(long[] array) {
    if (array.Length != 0) //conditional check should be present
    m_stream.ForceReadAlign(Aligns.Align8); // align first element only

  • Matthew Waller

    Matthew Waller - 2011-04-14


    I encountered this issue and the workaround suggested works well.

    However I have also had issues with the inverse case where I receive CORBA Marshall exceptions on invocation of a method taking a complex struct with an empty sequence of in my case doubles. Applying the same fix to the corresponding Write*Array() methods appears to have solved the issue.

    It was not evident from the previous comment that both the read and write methods needed the conditional checking so just thought I would make a note of it.


  • Alexander Kornienko

    • status: open --> closed-fixed
  • Alexander Kornienko

    fixed in rev 2018.
    thanks to all for pointing out to this issue and the solution!


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks