Tests segfault with C++17 #12104
Comments
antonio-rojas
added
the
untriaged
deannagarcia
removed
the
untriaged
|
This is coming from a death test, where we expect a crash. Are you actually seeing a test failure? If so could you provide a more complete log? googletest handles death tests by spawning a new process and analyzing the crash. |
Here is the full output of ctest |
|
That's a very different error. There's no stack trace and it's failing on a different test? |
|
There were many core dumps (probably because all of the previous tests) and I may have posted the wrong one. This looks more like it: |
|
Minimal test case: |
|
This general issue is still relevant with v23.0-rc1. I've been building protobuf for Fedora 38 and Rawhide for testing purposes which uses GCC 13 (defaulting to This commit may have been removed too hastily without further coverage of newer standards in testing... It's also a bit of a giveaway that the Bazel config is enforcing C++14 for compilation. |
|
Is the issue that the segfault only happens with C++17? That's really surprising since we do a lot of testing for C++17, but that would help narrow this down |
|
Yes, it only happens with C++17 |
This crash was due to the fact that we were passing `nullptr` as a `const char*` parameter and relying on that implicitly converting into an empty `absl::string_view`. `absl::string_view` supports that functionality, but starting with C++17 its behavior changes since it's just a type alias for `std::string_view`. `std::string_view` does not have any special conversion for nullptr and so we were just getting crashes. PiperOrigin-RevId: 530423047
This crash was due to the fact that we were passing `nullptr` as a `const char*` parameter and relying on that implicitly converting into an empty `absl::string_view`. `absl::string_view` supports that functionality, but starting with C++17 its behavior changes since it's just a type alias for `std::string_view`. `std::string_view` does not have any special conversion for nullptr and so we were just getting crashes. PiperOrigin-RevId: 530423047
This crash was due to the fact that we were passing `nullptr` as a `const char*` parameter and relying on that implicitly converting into an empty `absl::string_view`. `absl::string_view` supports that functionality, but starting with C++17 its behavior changes since it's just a type alias for `std::string_view`. `std::string_view` does not have any special conversion for nullptr and so we were just getting crashes. PiperOrigin-RevId: 530431663
|
Adding secondary confirmation that it's only with C++17. Against Fedora Rawhide I tried multiple permutations of the gtest, abseil-cpp, and protobuf packages with C++14 and C++17 and only having a complete C++14 chain worked (with the exception of json-cpp). Additional commentary in this Fedora PR: |
|
This is now fixed in d38ba32, and I am going to cherry-pick the fix into 22.x and 23.x. |
This crash was due to the fact that we were passing `nullptr` as a `const char*` parameter and relying on that implicitly converting into an empty `absl::string_view`. `absl::string_view` supports that functionality, but starting with C++17 its behavior changes since it's just a type alias for `std::string_view`. `std::string_view` does not have any special conversion for nullptr and so we were just getting crashes. PiperOrigin-RevId: 530431663
This crash was due to the fact that we were passing `nullptr` as a `const char*` parameter and relying on that implicitly converting into an empty `absl::string_view`. `absl::string_view` supports that functionality, but starting with C++17 its behavior changes since it's just a type alias for `std::string_view`. `std::string_view` does not have any special conversion for nullptr and so we were just getting crashes. PiperOrigin-RevId: 530431663
This crash was due to the fact that we were passing `nullptr` as a `const char*` parameter and relying on that implicitly converting into an empty `absl::string_view`. `absl::string_view` supports that functionality, but starting with C++17 its behavior changes since it's just a type alias for `std::string_view`. `std::string_view` does not have any special conversion for nullptr and so we were just getting crashes. PiperOrigin-RevId: 530431663
Fix crash in #12104 (cherry-pick)
|
@acozzette I can confirm that this fix allows testing to pass, however in a semi-related issue, Python will fail to build as it is hardcoded to use C++14: https://github.com/protocolbuffers/protobuf/blob/main/python/setup.py#L368-L373 So an additional patch(es) will be necessary to ensure across the entire project the CXX_STANDARD is consistent. |
|
What kind of error are you getting with the Python build? I'm not sure of the best solution for setup.py. We require at least C++14, but ideally users should be able to choose versions above that as well. |
|
Full build log here: https://download.copr.fedorainfracloud.org/results/mroche/protobuf/fedora-rawhide-x86_64/05906231-protobuf/builder-live.log.gz If you want to see the patches in use for that specific build (the setup has been modified since, but the general idea is the same): If you search the log above for I've successfully built by either:
I'm presently using the latter for Fedora builds as it makes the most sense for that specific context. |
What version of protobuf and what language are you using?
Version: 22.0 / git master
Language: C++
What operating system (Linux, Windows, ...) and version?
Linux x86_64
What runtime / compiler are you using (e.g., python version or gcc version)
GCC 12.2.1
What did you do?
cmake -B build -S protobuf
-DCMAKE_INSTALL_PREFIX=/usr
-Dprotobuf_USE_EXTERNAL_GTEST=ON
-Dprotobuf_BUILD_SHARED_LIBS=ON
-Dprotobuf_ABSL_PROVIDER=package
cmake --build build
cmake --build build --target test
What did you expect to see
Tests pass
What did you see instead?
Tests segfault
Anything else we should know about your project / environment
Same issue when using the bundled abseil-cpp. Building with C++14 makes test pass correctly.
The text was updated successfully, but these errors were encountered: