[omniORB] Assertion failure for structure in Any of omniORB 4.1.1

[Duncan Grisby]

On Friday 12 October, "Jian Wu" wrote:

[...]
> The error appears while the python client calling function f_vi() with
> this struct inside Any. The c++ server will give this output many times.
> 
> omniORB: Assertion failed.  This indicates a bug in the application
> using omniORB, or maybe in omniORB itself.
>  file: ../../../../../src/lib/omniORB/dynamic/tcParser.cc
>  line: 297
>  info: 0
> 
> However, if we make the following change of line 729-731 in tcParser.cc,
> all our test cases pass without any error:
> 
> void tcParser::copyStreamToStream(const CORBA::TypeCode_ptr tc,
> 			     cdrStream& src,
> 			     cdrStream& dest) {
> //  if (src.unmarshal_byte_swap() == dest.marshal_byte_swap())
> //    fastCopyUsingTC(ToTcBase_Checked(tc), src, dest);
> //  else
>     copyUsingTC(ToTcBase_Checked(tc), src, dest);
> }
> 
> Looking closer into function fastCopyUsingTC() in tcParser.cc, it has no
> switch on tc_struct and goes to default line 297. Is that the source of
> the error?

No, that's not the problem. The fast copy case uses an "alignment table"
that is generated from the TypeCode. Struct TypeCodes should never
appear in an alignment table, so it's right that the switch doesn't
handle the case of tk_struct. If there is a tk_struct TypeCode in there,
it's a bug in the code that generates the alignment table.

Something helpful would be if you add a log message just before the
assertion failure to show what TypeCode kind the switch has encountered.

> We also notice that tcParser.cc is exactly the same in version 4.1.0 and
> 4.1.1. Is it possible that the other changes in 4.1.1 make this problem
> appears in the new version.

The code that generates the struct alignment table, in typecode.cc, has
been changed, to fix a bug related to recursive structs. That is
presumably the cause of the error, but I can't see a problem just be
reading the code.

> In the attachment you will see all the idl types used in Any in our test
> suite. The only failure cases are:

Are you able to come up with a minimal test case that fails?  It's very
difficult to see what's going on in that big generated IDL file. Also,
it #includes and uses types from a couple of other files that you didn't
provide. It would be really handy if you could provide code that fails,
as well as just the IDL. That will make it much easier for me to
reproduce it.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --