Extra data at the end would definitely be a problem. That could cause
parsing to return an error, or it might happen to be in the right format so
that it gets parsed as an unknown field (or even a regular known field).
If the serialization returns an error there isn't an API to get more
details
For both messages I think it returned 10, although the actual data for the
second one was wrong. I think that extra data might just be copying extra
data from the string printed in my log. Would extra data at the end of
serialized data affect actual deserialization? Cause the first one
What does pak.ByteSize() return for those two messages? It would also be
good to verify that SerializeToArray() is returning true, because if not
then there could be an error being missed.
Something seems to be going wrong with the message sizes, because the first
data example seems to have extra
Well I just copied whatever text was printed after i logged what was being
serialized. So I probably copied extra bytes not sent from first one (since
first one deserializes fine). It seems like I'm using correct api call to
do serialization (and it works with other data combos/types)
The
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
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
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
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
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
First thought: what language / platform is this? the C++ generated code is
very different to the Java generated code, for example
Second thought: 2.6 is pretty old; it is very possible that a bug existed
and has been fixed since then (Aug 2014) - does it still happen with more
recent releases?
Hi,
I have a strange case I'm dealing with. Using protobuf compiler 2.6.
Every time I send a certain set of values over my socket, it ends up with
missing data. Although I've compared the string received after
serialization on the server and on receiving the string on the client and
they are
11 matches
Mail list logo
