[jira] [Updated] (AVRO-2202) Use of -fstack-protector or -D_GLIBCXX_DEBUG causes memory corruption when combined with musl libc static builds

["Josh Scoggins (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/AVRO-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josh Scoggins updated AVRO-2202:
--------------------------------
    Description: 
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 happening, 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. 

  was:
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. 


> 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
>            Priority: Major
>
> 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 happening, 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)