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
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
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
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
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
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