Open KerstinKeller opened 2 hours ago
That seems quite surprising considering that the message being encoded there doesn't have any bool
fields.
There was a recent bug in Firebase with very similar backtrace, but I think it was very Xcode-specific and was caused by corruption of the _fields
array.
I do think that corruption of the _fields
array is the only way pb_enc_bool
could get called for a message that does not contain it. The type index for bool
is 0x00, so if the fields array is accidentally zeroed out, it will end up calling pb_enc_bool
.
If you are able to add logging that would hex dump eCAL_pb_LogMessage_fields
that could give some clues.
Also if you have more details on the backtrace, such as function arguments or SIGSEGV pointer value, that is helpful.
We've migrated from using the C++ Protobuf implementation to nanopb for the middleware eCAL on our master branch.
So far we haven't had any problems on our dev platforms, but now users reported a SIGSEV thrown in the
safe_read_bool
function. We're currently using nanopb 0.4.8 (but upgrade would be no problem).However, we're really at loss, if this is a potential nanopb bug, or if we're doing something wrong trying to encode the protobuf messages. The call stack goes through
safe_read_bool
,pb_enc_bool
,encode_basic_field
encode_field
andpb_encode
, which is called from our encoding function.What could we be doing wrong that may cause the segmentation fault? Thanks for the help.