You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avro.apache.org by "Josh Scoggins (JIRA)" <ji...@apache.org> on 2018/07/26 17:03:00 UTC
[jira] [Created] (AVRO-2202) Use of -fstack-protector or
-D_GLIBCXX_DEBUG causes memory corruption when combined with musl libc
static builds
Josh Scoggins created AVRO-2202:
-----------------------------------
Summary: Use of -fstack-protector or -D_GLIBCXX_DEBUG causes memory corruption when combined with musl libc static builds
Key: AVRO-2202
URL: https://issues.apache.org/jira/browse/AVRO-2202
Project: Avro
Issue Type: Bug
Components: c++
Affects Versions: 1.8.2
Environment: OS: Gentoo Linux
Compiler: Gcc 6.4.0 targeting musl libc 1.19 with stdlibc++ in a static build
Reporter: Josh Scoggins
Observed with master and version 1.8.2. Inside of the C++ implementation's CMakeLists.txt the lines 56-60 were added sometime in 2016 which activate features inside of libstdc++ to help find errors. This change has two side effects:
# -g is eliminated from the build so debugging gdb becomes harder as source position data has been removed
# The safety containers that implicitly wrap all standard containers somehow (I can't figure out exactly how) cause memory corruption when setMetadata is called (in version 1.8.2) or when a Writer object is destroyed (on master). Since our software uses musl libc with libstdc++ I believe that it is an interaction with these debugging features which cause memory corruption (as I said, I have no clue _why_ it is happen, only that these features _cause_ it :()
Previously, we were using 1.7.7 which did not have these lines in its CMakeLists.txt and thus did not exhibit any sort of memory corruption. I was able to work around this by removing lines 56-60 from CMakeLists.txt so our static libs could be built and our unit tests not crash by writing to memory it did not own. There should be a toggle or something similar to turn off these features for debug builds as they are for developers of avro only.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)