1

I made a ProtocolBuffer object from the proto class I usually use and I need to Serialize it. Now, I take the object and call SerializeToArray() on it like this:

int size = messageObject.ByteSize();
void* buffer = malloc(size);
messageObject.SerializeToArray(buffer, size);

As far as I know there is no problem with this since the object has data in it (I checked it by breaking right before the Serialize line).

When the method calls however it triggers an abort() which I don't know anything about. I have no idea what it could be. The only data that is included in this object is a "type" enumerator (which I can set to the type of data that is being used in this object since it can include different sorts of messages) and it holds one message object of the repeatable type.

message MessageID 
{
    enum Type { LOGINDATA = 1; PLAYERDATA = 2; WORLDDATA = 3; }

    // Identifies which field is filled in.
    required Type type = 1;

    // One of the following will be filled in.
    repeated PlayerData playerData = 2;
    optional WorldData worldData = 3;
    optional LoginData loginData = 10;
}

This is the base message. So, Type is 2 in this case which stands for PLAYERDATA. Also, playerData is being set with a single object of the type PlayerData.

An help is appreciated.

Dries
  • 995
  • 2
  • 16
  • 45

1 Answers1

2

Any time that the protobuf library aborts (which, again, should only be in debug mode or in sever circumstances), it will print information about the problem to the console. If your app doesn't have a console, you can use google::protobuf::SetLogHandler to direct the information somewhere else:

https://developers.google.com/protocol-buffers/docs/reference/cpp/google.protobuf.common#SetLogHandler.details

typedef void LogHandler(LogLevel level, const char* filename,
                        int line, const std::string& message);
LogHandler* SetLogHandler(LogHandler* new_func);

The protobuf library sometimes writes warning and error messages to stderr.

These messages are primarily useful for developers, but may also help end users figure out a problem. If you would prefer that these messages be sent somewhere other than stderr, call SetLogHandler() to set your own handler. This returns the old handler. Set the handler to NULL to ignore log messages (but see also LogSilencer, below).

Obviously, SetLogHandler is not thread-safe. You should only call it at initialization time, and probably not from library code. If you simply want to suppress log messages temporarily (e.g. because you have some code that tends to trigger them frequently and you know the warnings are not important to you), use the LogSilencer class below.

The only reason for an abort that I know of (which only applies in debug builds) is if some required field isn't set. You say that the type field is set, so there must be a required field in PlayerData which is not set.

Kenton Varda
  • 41,353
  • 8
  • 121
  • 105
  • Amazing explanation. Thanks for that :) I figured it out though. Apparently the data has to be set in order for it be okay (I added parts at random with other things in between) – Dries Jul 25 '14 at 10:48