Re: [protobuf] Protobuf 2.6 serialization weird behavior

2018-04-10 Thread Tony Tony
c++/windows I'll upgrade protobuf and see if issue goes away. Just wanted to make sure I'm not missing anything. Is there any additional troubleshooting I can look into to troubleshoot further if the recent release reproduce the issue? On Tuesday, April 10, 2018 at 1:46:50 AM UTC-4, Marc Gravel

Re: [protobuf] Protobuf 2.6 serialization weird behavior

2018-04-10 Thread Marc Gravell
Well, if it was me: the first thing I'd do is isolate whether it is serialize or deserialize that is failing - by taking your currently serialized data as a flat file or byte dump, and checking whether the values are right or wrong. Depending on the volume and layout of the data, you might be able

Re: [protobuf] Protobuf 2.6 serialization weird behavior

2018-04-10 Thread 'Adam Cozzette' via Protocol Buffers
I think Marc is right that it would be best to isolate the problem by manually checking that the bytes are valid. Tony, how are you framing the messages? Protocol buffers do not describe their own size and so you have to know what size to expect before you parse a proto. The typical approach is to

Re: [protobuf] Protobuf 2.6 serialization weird behavior

2018-04-10 Thread Tony Tony
So I upgraded to 3.5.0, same issue. I guess I should give some more information: I'm basically using protobuf to serialize/deserialize string data I'm sending through a games socket implementation via hooks/code caves in the games network engine. I currently can validate that the bytes after se

Re: [protobuf] return to arena (C++)

2018-04-10 Thread 'Feng Xiao' via Protocol Buffers
Arena is not supposed to be used as a memory pool. The recommended pattern is to use one arena per rpc request/response. You can tweak that to one arena multiple rpc request/response but the number of messages you want to put into the arena should be limited. It won't work well if you use one arean

Re: [protobuf] Protobuf 2.6 serialization weird behavior

2018-04-10 Thread Marc Gravell
Oddly neither of those is correct! The actual hex should be: 08-03-1A-06-08-01-10-63-18-01 which is the first version minus some trailing data. The second version is not valid at all - it isn't just missing data: it is an incomplete and invalid payload. Unfortunately I'm not familiar enough with