Archived

This forum has been archived. Please start a new discussion on GitHub.

slice2cpp streaming API bug with nested modules

Hello Ice Team,

I came across into following problem: if nesting level of modules is larger than 2 (or 3, I'm not sure how it is calculated) then streaming API generated by slice2cpp is not correct (it fails during runtime). Here is an example based on cpp/demo/Ice/invoke:

//modified part of Printer.ice
module Demo{
...
module x {
module dto
{

struct Structure
{
string name;
Color value;
};

sequence<Structure> StructureSeq;

class C
{
Structure s;
};
};
};
...
//interface methods changed to use nested module names for Structure, StructureSeq and C
};

//Client.cpp and PrinterI.cpp modified to use nested module names for Structure, StructureSeq and C

Everything compiles well except that client generates runtime error when serializing Structure, StructureSeq or C:
client: ../../../include/Ice/Stream.h:202: static void Ice::StreamWriter<st>::write(const Ice::OutputStreamPtr&, const T&) [with T = Demo::x::dto::Structure, Ice::StreamTraitType st = (Ice::StreamTraitType)10u]: Assertion `false' failed.
Aborted

There is no error when there is only one more nesting level, I mean using only "x" module (without "dto") will give no error. Tested with: "c++ (Ubuntu 4.4.1-4ubuntu9) 4.4.1".

Please confirm it's a bug, I could not find such limits in Ice manual.

Edit:
forgot to mention that Ice version is 3.4.0 (current) and 3 patches for slice2cpp (posted on "Patches" forum) were applied.

Best regards
Przemek

Comments

  • mes
    mes California
    Hi,

    Thanks for bringing this to our attention, it does indeed look like a bug in the generated code.

    Regards,
    Mark
  • Hello,

    Thanks for quick reply. After any error correction it might be not so safe to leave it as it is now. Is it possible to refactorize this piece of code (I mean "assert(false)" in Stream.h) in order to throw errors during compile time instead of aborting application? This step may prevent similar cases in the future.

    I also hope that simple remote calls does not use the streaming API in some circumstances because it would be a disaster for exisitng systems.

    Best regards
    Przemek
  • mes
    mes California
    Hi,
    PrzemekD wrote: »
    I also hope that simple remote calls does not use the streaming API in some circumstances because it would be a disaster for exisitng systems.
    This bug only affects the code generated for our portable streaming API. Regular Ice invocations do not use this code.

    Regards,
    Mark