Archived
This forum has been archived. Please start a new discussion on GitHub.
Ice not detecting changes of type in splice file
Hi all,
We recently changed the definition inside a struct from double to int, and the clients (using the old definition) didn't appear to notice the change. This resulted in invalid memory access leading to strange problems.
I would have expected a marshalling or some other kind of error instead of receiving garbage...
Especially, considering that it will (I believe) detect a name change in the variables!
Here is the definition we modified:
struct TInterestRateTerm
{
string term;
double nbDays;
SeqInterestRate interestRates;
};
sequence< TInterestRateTerm > SeqInterestRateTerm;
It was changed to:
struct TInterestRateTerm
{
string term;
int nbDays;
SeqInterestRate interestRates;
};
sequence< TInterestRateTerm > SeqInterestRateTerm;
The server is in C++, the clients were in .NET or C++. Both client didn't see anything. This is using the latest 3.4.2 ICE on 64bit Windows.
We recently changed the definition inside a struct from double to int, and the clients (using the old definition) didn't appear to notice the change. This resulted in invalid memory access leading to strange problems.
I would have expected a marshalling or some other kind of error instead of receiving garbage...
Especially, considering that it will (I believe) detect a name change in the variables!
Here is the definition we modified:
struct TInterestRateTerm
{
string term;
double nbDays;
SeqInterestRate interestRates;
};
sequence< TInterestRateTerm > SeqInterestRateTerm;
It was changed to:
struct TInterestRateTerm
{
string term;
int nbDays;
SeqInterestRate interestRates;
};
sequence< TInterestRateTerm > SeqInterestRateTerm;
The server is in C++, the clients were in .NET or C++. Both client didn't see anything. This is using the latest 3.4.2 ICE on 64bit Windows.
0
Comments
-
Hi Julien,
Could you detail the error you got? I'm not sure what your referring to with the un-marshalling code detecting variable name changes, no variable names go on the wire so changing a variable name shouldn't have any effects on the marshaling (changing the order of data members would however change how the data is marshaled).
The un-marshalling is driven by the Slice definition of the receiver (for efficiency, Ice doesn't transmit any type definitions over the wire). So if you change a double to an int, the receiver might or might not detect the change depending on the next parameter to un-marshall and its value. In your case, the receiver will un-marshall less data for nDays. The un-marshalling will therefore un-marshal an invalid SeqInterestRate, this might or might not work depending on the data and the type.
In any case, Ice should never crash under such circumstances, the marshaling will either succeed and return invalid data or it will fail with a marshaling exception. If you got a crash, this is a bug and it would be great if you could provide us with some instructions to reproduce so that we can fix it.
It is important that the client and server use the same Slice definitions. One way to ensure this is to compare the Slice checksums of the client and server. If the checksums are equal in the client and the server, you know that the types will be on-the-wire compatible (the checksums equality provides even stronger guarantees since they are also computed based on the parameter or data member names... perhaps this is what you were referring with data member name changes?).
Cheers,
Benoit.0 -
Hi Benoit,
Thanks for the info. Sorry about the confusion about the name variable, after some changes I did to change the name of a variable inside a structure, the guy writing the .NET client reported he was having an ICE system error. The pb disapeared after updating the ICE file, so I assumed it was the name change that caused a pb. From what you say, I was wrong...
The error the client was getting from changing from double to int, depended on the size of the structure. But he was mainly getting errors about invalid encoding for the date string par of the interest rates sequence.
So ICE is not crashing, just reporting errors while marshalling or returning invalid data (just as you said
).
We will probably follow your advice about checksums on ICE definitions. I believe Bernard recommended this as well when he was on site for his ICE presentations..
Thanks a lot!
Julien0
