search

nanopb / nanopb

Protocol Buffers with small code size
https://jpa.kapsi.fi/nanopb/
zlib License
4.34k stars 854 forks source link

SIGSEV in safe_read_bool #1029

Open KerstinKeller opened 2 hours ago

KerstinKeller commented 2 hours ago

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 and pb_encode, which is called from our encoding function.

What could we be doing wrong that may cause the segmentation fault? Thanks for the help.

PetteriAimonen commented 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.