How can unknown fields appear in a message?

[Michael Videlgauz]

Hello!

I am now investigating a bug in my program under debugger (VS2008
IDE). I see that some my messages have unknown fields set. I don't use
any executable compiled with old proto files, whenever I change my
proto file I rebuild entire project with new pp.h and pb.cc sources.
Even more, I have reverted my recent changes in proto and now I have
it exactly the same as it was when project was built very first time
(I mean there is no chance that executable compiled with a different
proto exists anywhere). Still I am getting those unknown fields - I
see under debugger that message destructor iterates over unknown field
set and deletes them one by one. The value of fileds is a string that
I do set in my program and 'numbers' (if I guess correctly they are
field's tags) are 5 and 7 - tags that always existed in my proto from
very first time it was compiled...

[Pherl Liu]

Can you try to print the DebugString() of the message containing unknown fields? One possibility is you used the wrong message type to parse the bytes.

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To post to this group, send email to prot...@googlegroups.com.
To unsubscribe from this group, send email to protobuf+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.

[Michael Videlgauz]

Thanks for your reply! I have found a bug in my software.

I didn't know that string field of a message considered as already
created by protobuf code if it points not to default string,
set_<fieldname>() method first compares those pointers and only calls
'new' if they are different. Next, I passed a message created in one
DLL into another DLL. Those DLL are assembled with individual
instances of proto lib, so addresses of default string instances were
different in the context of different DLLs. Second DLL called
set_<fieldname>() method actually not creating it (and destroying
default string in the memory of first DLL of course). Then, I had a
number of subsequences of this bug... I am wondering why IsSet()
(bitmask that indicates what fields are set) is not used in the
set_<fieldname>() code instead of comparing address with address of
default string, but anyway now I understand that I must not try to
access deserialized message created in the context of a different
instance of prtotolib...

But now I have a different problem and I will really appreciate it if
could put some light on it. I am now trying to use unknown fields to
extend a message with a fields that are not known by the code that
created that message. Yes I remember about tag numbers so I am adding
new fields with tags 1000, 1001... (original message is created with
about 5 fields with tags 1-5). Then message is serialized, sent over a
network and received by another process. The receiver process knows
type of this message (it was compiled with same .proto file).

After deserialization (I am using msg-ParseFromString()) only fields
declared in proto get assigned in new message, but unknown_fields set
is empty. Isn't ParseFromString() supposed to read all fields from the
string including unknown?

On Sep 22, 6:59 am, Pherl Liu <liuj...@google.com> wrote:
> Can you try to print the DebugString() of the message containing unknown
> fields? One possibility is you used the wrong message type to parse the
> bytes.
>

[Michael Videlgauz]

Sorry, please disregard my last question. I think this is my problem
again... ((((