Same issue here, setting with an uninitialized boolean. Pretty much took my
whole week to figure out this was the problem. It was different surfacing
though, it instead was crashing with *CHECK failed !coded_out.HadError() *.
I figured out the buffer was too small for the info we were trying to
Wow, same issue over here, 7 years later practically to the day! Your
comment was a major hint at where to look
(uninitialized/experimental/unused vars are definitely a known weakness of
my team).
On Monday, February 6, 2012 at 9:54:19 PM UTC-5, Robby Zinchak wrote:
>
> Ah, thank you very much
I found another reason this can happen: If you compile with an `-march`
newer than the target CPU.
For example, if I compile a minimal protobuf example
using SerializeToArray() using `-march=haswell` and execute it on a Sandy
Bridge CPU, I get:
[libprotobuf FATAL
I have same problem now, and there is no uninitialized boolean attr
On Tuesday, February 7, 2012 at 11:45:29 PM UTC+8, Evan Jones wrote:
>
> On Feb 6, 2012, at 21:54 , Robby Zinchak wrote:
> > It turned out to be an uninitialized boolean. Properly setting the
> value in question seems to allow
On Feb 6, 2012, at 21:54 , Robby Zinchak wrote:
It turned out to be an uninitialized boolean. Properly setting the value in
question seems to allow things to proceed normally.
Ah! Interesting. So one of your .set_* properties is a boolean, and one of them
was uninitialized? That would do it.
Hello,
I have been using protobuf successfully for my project for a number of
months now when I compile my project in gcc. Recently I went to
compile my project in gcc with the -O optimization flag, but when
running the project, I soon get an error when attempting to call
SerializeAsString():
This is weird. I don't see any clear potential cause, so I have a few questions:
HTMud::EnvAdd item;
item.set_id(ID);
item.set_idtype(typeID);
item.set_x(X);
item.set_y(Y);
item.set_z(Z);
item.set_lockdown(lockdown);
item.set_mapid(map);
item.set_tilesetno(tilesetNo);
Ah, thank you very much Evan.
It turned out to be an uninitialized boolean. Properly setting the value
in question seems to allow things to proceed normally.
Thanks again,
Robby
On Mon, Feb 6, 2012 at 11:09 AM, Evan Jones ev...@csail.mit.edu wrote:
This is weird. I don't see any clear
