For about 2 weeks I've been having a strange problem I really can't wrap my head around.
A quick background: On my server app, I create a series of objects (each object with 32 bit length prefixes) and every so often I send a bunch of objects to the client. This is handled by lidgren which is pretty reliable and I don't think it's the cause of my problems.
On my client, I do this (also, it's worth mentioning that Object.Base is inherited by tons of objects):
public void ReadEntities(NetIncomingMessage Message)
{
int Count = Message.ReadInt32();
for (int i = 0; i < Count; i++)
{
ReadObject(Message);
}
}
public void ReadObject(NetIncomingMessage Message)
{
int Length = Message.ReadInt32();
Deserialize(Message.ReadBytes(Length));
}
public Object.Base Deserialize(byte[] Bytes)
{
MemoryStream SerializeStream = new MemoryStream(Bytes);
Object.Base NewObject = Serializer.Deserialize<Object.Base>(SerializeStream);
Object.Base ObjectExist = null;
ObjectExist = Scene.GetEntity(NewObject.ID);
if (ObjectExist == null)
{
NewObject.Initialize();
return NewObject;
}
else
{
SerializeStream.Seek(0, SeekOrigin开发者_运维问答.Begin);
Serializer.Merge<Object.Base>(SerializeStream, ObjectExist);
return ObjectExist;
}
}
It works perfectly... usually. Several updates happen where objects are deserialized and merged properly. After a few seconds though, an error pops up saying there was a StackOverflowException in protobuf-net or mscorlib. This error goes away when I comment out the Serializer.Merge line. Naturally, I pretty much need to use Merge for this update design to work. Furthermore, it's clearly able to deserialize since I only comment out the merge line; it's Merge which is being problematic. Really at my wits' end for this.
Ooh, that is...odd; I don't do anything non-deterministic in there (I'm the author, btw). I don't think I've got enough there for a repro (in particular, I don't know your type-model nor your specific data).
I'm more than happy to help, but I might need a bit more to reproduce that. In Visual Studio, you can generally capture part of a blown stack in the "Call Stack" window, which should give some indication of there the problem is. Alternatively, if you are able to post more specific information (so that I can reproduce it), either here or directly, we'll get to the bottom of it.
I'm going to make the assumption that you are using r282 (the current downloadable dll); you could also try using the alpha build of v2; since I don't know what the problem is (yet) I can't state that this will fix it, but if it does work reliably it will point at a bug in v1 (r282).
Another possibility is that there is something in your type model that is tying it in knots; perhaps some atypical getter/setter that is causing problems.
精彩评论