Use of repeated

[sksh...@gmail.com]

I am experimenting with "repeated" fields my dot-proto is as follows:

message Foo {
required string name = 1;
optional int32 id = 2;
optional int32 num = 3;
repeated string sbr = 4;
repeated int32 wrk = 5;
}

I build the msg and use foo.SerializeToString(&str) and then sending
the retult str.c_str() over a socket;

On the receiving end I get the following:

libprotobuf FATAL /usr/local/include/google/protobuf/repeated_field.h:
513] CHECK failed: index < size():
Aborted

If I eliminate the repeated fields from the msg then it all works
fine.

[Henner Zeller]

On Tue, Jun 16, 2009 at 7:48 PM, sksh...@gmail.com<sksh...@gmail.com> wrote:
>
> I am experimenting with "repeated" fields my dot-proto is as follows:
>
> message Foo {
>    required string     name        = 1;
>    optional int32      id             = 2;
>    optional int32      num             = 3;
>    repeated string     sbr             = 4;
>    repeated int32      wrk             = 5;
> }
>
> I build the msg and use foo.SerializeToString(&str) and then sending
> the retult str.c_str() over a socket;

So how do you determine the length of the data you transmit ? c_str()
returns a NUL terminated string. The serialized data might contain a
NUL character somewhere inbetween. If you use use the result of
c_str() to determine the length (like with strlen()), your message
might get truncated. Always use the size() call of the std::string to
determine the size, never something like strlen() or printf("%s") or
something.

Note as well, that a write() might only write the data partially (in
particular to a socket); its return value tells you how much it
actually has written; so write() calls you always need to encapsulate
in a loop.

So your problem is probably not related to repeated fields, but might
be related to how you do the transport; the repeated fields might just
have triggered it if they contain a NUL terminated string.
-h

[Kenton Varda]

Can you please send me example code which crashes when given invalid input, and/or provide a stack trace for the crash?

Henner touched on some reason why the data may not have been correctly transmitted.  However, no input should ever cause the protobuf parser to crash.

On Tue, Jun 16, 2009 at 7:48 PM, sksh...@gmail.com <sksh...@gmail.com> wrote:

[Sushil Shelly]

Henner, Kenton,

thank you both for your responses ( using c_str() ) has not been the issue so far.

The bug was in my test code,
issue-1) I was accessing one of the "repeated" fields prior to actually adding the filed first (this was on the send side)

issue-2) I was again accessing "repeated" field that did not exist. ie only two elements are added and I was accessing the third one (I started at index 1, rather than index 0).

Some suggestions.

• Attempting to write to a non-existing element should throw and exception,
• Attempting to read from a non-existing element should also throw an exception

thanks,

Sushil

ps: I am planing to continue testing with nested messages. Does the generated code provide provisions for iterators. Can the repeated fields be saved using vector< repeated-type >. the message would look something like this:

message Foo {
    optional sequence< int32 > sequence_of_int32 = 1;

[Kenton Varda]

On Thu, Jun 18, 2009 at 8:44 PM, Sushil Shelly <sksh...@gmail.com> wrote:

Some suggestions.

• Attempting to write to a non-existing element should throw and exception,
• Attempting to read from a non-existing element should also throw an exception

At Google we've made the decision not to use C++ exceptions, because it's too difficult to ensure that all code is exception-safe.  Instead, we generally either assert-fail or log error messages to the console.  In both of the cases you mention, the code will assert-fail, as you saw.

 

ps: I am planing to continue testing with nested messages. Does the generated code provide provisions for iterators. Can the repeated fields be saved using vector< repeated-type >. the message would look something like this:

RepeatedField and RepeatedPtrField both support STL-like iterators, but they are not vectors.  See documentation for repeated_field.h.