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 
store, and my boss pointed out "Huh, that's weird, because it should be 
showing this error (the one you got) instead: 

CHECK failed:
(bytes_produced_by_serialization) == (byte_size_before_serialization):
Byte size calculation and serialization were inconsistent. This may
indicate a bug in protocol buffers or it may be caused by concurrent
modification of the message.

I don't know why we didn't get to that point, but thank goodness his 
insight led me here. Posting my version in the hopes of helping someone 
else in the future. 
On Tuesday, February 5, 2019 at 12:30:06 PM UTC-5 Andrey O wrote:

> 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 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 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);
>>> > item.set_tilesetx(tilesetX);
>>> > item.set_regionx(regionX);
>>> > item.set_regiony(regionZ);
>>>
>>>
>>> Are all these values primitives? Are any of them protocol buffers?
>>>
>>> Have you tried dumping the values that are being set when it dies, and 
>>> trying a standalone program that sets the values and calls 
>>> SerializeToString to see if it has the same problem?
>>>
>>> Have you made any changes to the protocol buffers library? I'm assuming 
>>> you are using the released version of 2.4.1?
>>>
>>> Have you tried running this under valgrind? I'm wondering if there could 
>>> be other weird memory corruption that is happening? That seems to be a 
>>> frequent cause of "this shouldn't be happening" type errors, particularly 
>>> things that appear/disappear occur with optimization enabled/disabled.
>>>
>>> Evan
>>>
>>> --
>>> http://evanjones.ca/
>>>
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/protobuf/9ffde66b-7916-4256-91b3-b2a2358d7e62n%40googlegroups.com.

Reply via email to