Description
What version of protobuf and what language are you using?
Version: main
Language: C++
What operating system (Linux, Windows, ...) and version?
Windows & Mac
What runtime / compiler are you using (e.g., python version or gcc version)
clang
What did you do?
Several related:
- Crash on deserialization of repeated field when using Clang 19 on Windows #20482
- segfault installing on MacOS Sequioa netheril96/securefs#198
- https://github.com/netheril96/securefs/actions/runs/14469406964/job/40579294047
The key problem is that the libprotobuf and the protobuf generated code are built by different compilers. In the first case, libprotobuf is built by MSVC and the generated code by clang-cl 19. In the second case, libprotobuf is built by an older version of clang and the generated code by a newer version.
In both cases, the compiler for the generated code has support for __is_bitwise_cloneable, and therefore EnableCustomNew is true. The generated code then creates MessageCreator with func == nullptr (here).. But the library is built by a compiler without such functionality, and because of that, this is always true, and it blindly dereferences a null pointer func even though tag is not kFunc, causing SIGSEGV.
What did you expect to see
Library and generated code can be built by different compilers and linked together as long as they are ABI compatible.
Although inside Google everything is always built together by the same compiler, the outside world expects differently. In the world outside Google, libprotobuf is usually provided by a package manager rather than built together as the consumer source code, so compiler version match is widely present.
What did you see instead?
When the generated code is built by a newer version of compiler, the linked binary may crash with SIGSEGV.
Anything else we should know about your project / environment