"free(): invalid pointer" when using CPR with conan

[TruncatedDinoSour]

Description

When using CPR with conan I get this error when trying to run the binary

free(): invalid pointer
Aborted

Expected Behavior

Should work

Actual Behavior

It breaks

Possible Fix

Steps to Reproduce

1. Use CPR with conan

Context

I was trying to reach out to a website and get the response body/text.

Your Environment

• Version used: 1.6.2
• Where did you get it from (e.g. conan, vcpkg, master, ...): conan
• Operating System and version: Linux ari-gentoo 5.14.2-gentoo Multipart form POST upload #1 SMP Thu Sep 9 18:26:44 EEST 2021 x86_64 Intel(R) Core(TM) i3-8130U CPU @ 2.20GHz GenuineIntel GNU/Linux
• Link to a small example: https://replit.com/@B00bleaTea/ghufhuerhyur4gyfghryfhryhfyufhurehufberfhberhbfhuerbfhuerf#main.cpp

Run this when trying the example (in the shell tab):

chmod a+rx ./build.sh

./build.sh

./bin/conantest 'https://google.com'

[TruncatedDinoSour]

I closed it because I thought it might have been my issue, but doesn't look like it

[COM8]

I can confirm this one. Thanks for reporting.
Looks like this happens just with the conan package.

This happens when calling the default destructor of cpr::Response.

[COM8]

Since you are using CMake try this instead:

cmake_minimum_required(VERSION 3.16)

project(conantest CXX)

add_executable(${PROJECT_NAME} main.cpp)

include(FetchContent)
FetchContent_Declare(cpr GIT_REPOSITORY https://github.com/whoshuu/cpr.git GIT_TAG f4622efcb59d84071ae11404ae61bd821c1c344b) # the commit hash for 1.6.2
set(CPR_BUILD_TESTS OFF CACHE INTERNAL "" FORCE)
set(CURL_CA_FALLBACK ON CACHE INTERNAL "" FORCE) # Workaround for failing SSL requests
FetchContent_GetProperties(cpr)
if(NOT cpr_POPULATED)
  FetchContent_Populate(cpr)
  # Do not add install targets for cpr
  add_subdirectory(${cpr_SOURCE_DIR} ${cpr_BINARY_DIR} EXCLUDE_FROM_ALL)
endif()

target_link_libraries(${PROJECT_NAME} cpr::cpr)

mkdir build
cd build
cmake ..
cmake --build .

[TruncatedDinoSour]

Since you are using CMake try this instead:

cmake_minimum_required(VERSION 3.16)

project(conantest CXX)

add_executable(${PROJECT_NAME} main.cpp)

include(FetchContent)
FetchContent_Declare(cpr GIT_REPOSITORY https://github.com/whoshuu/cpr.git GIT_TAG f4622efcb59d84071ae11404ae61bd821c1c344b) # the commit hash for 1.6.2
set(CPR_BUILD_TESTS OFF CACHE INTERNAL "" FORCE)
set(CURL_CA_FALLBACK ON CACHE INTERNAL "" FORCE) # Workaround for failing SSL requests
FetchContent_GetProperties(cpr)
if(NOT cpr_POPULATED)
  FetchContent_Populate(cpr)
  # Do not add install targets for cpr
  add_subdirectory(${cpr_SOURCE_DIR} ${cpr_BINARY_DIR} EXCLUDE_FROM_ALL)
endif()

target_link_libraries(${PROJECT_NAME} cpr::cpr)

mkdir build
cd build
cmake ..
cmake --build .

thank you, works

[KingKili]

I am reopening this issues since this seems to be a workaround, and no solution.

[KingKili]

I can confirm this one. Thanks for reporting.
Looks like this happens just with the conan package.

This happens when calling the default destructor of cpr::Response.

I dug a little deeper using a debug build of cpr. To be exact it is happening when the destructor of 'cpr::StringHoldercpr::Url::~StringHolder'.
Strangely the value of 'str_' is definitely invalid. What is also counter-intuitive (for me) that the 'StringHolder(const std::initializer_liststd::string args))' constructor is being used. @COM8 do you agree that this is the wrong constructor for this example?

[COM8]

For me this make sense since there is no other valid ctr that takes only a const char*, so I guess StringHolder(const std::initializer_list<std::string> args) is being chosen.

[adventurist]

Confirming I've also hit this

[COM8]

@ollien Could you have a look into this, since you created the latest Conan package for cpr and it looks to be a Conan related issue.

[KingKili]

I tried version 1.5.0 from conan, resulting in the same crash. It does not seem like the bug was introduced with the 1.6.2 release.

[ollien]

@COM8 yep, I'll take a look as soon as I can. I'm confused how this happened

[ollien]

@COM8 Could you give me more information about the environment you're hitting this under? Namely the compiler/version? With g++10 and clang11 the given code in the issue works without issue on my machine.

For the record, I did this under the conanio/gcc10 and conanio/clang11 docker containers.

root@e45ce7556027:/test# clang++ test.cpp @conanbuildinfo.args
root@e45ce7556027:/test# ./a.out 'https://example.com'
<!doctype html>
<html>
<head>
    <title>Example Domain</title>

    <meta charset="utf-8" />
    <meta http-equiv="Content-type" content="text/html; charset=utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <style type="text/css">
    body {
        background-color: #f0f0f2;
        margin: 0;
        padding: 0;
        font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", "Open Sans", "Helvetica Neue", Helvetica, Arial, sans-serif;
        
    }
    div {
        width: 600px;
        margin: 5em auto;
        padding: 2em;
        background-color: #fdfdff;
        border-radius: 0.5em;
        box-shadow: 2px 3px 7px 2px rgba(0,0,0,0.02);
    }
    a:link, a:visited {
        color: #38488f;
        text-decoration: none;
    }
    @media (max-width: 700px) {
        div {
            margin: 0 auto;
            width: auto;
        }
    }
    </style>    
</head>

<body>
<div>
    <h1>Example Domain</h1>
    <p>This domain is for use in illustrative examples in documents. You may use this
    domain in literature without prior coordination or asking for permission.</p>
    <p><a href="https://www.iana.org/domains/example">More information...</a></p>
</div>
</body>
</html>

EDIT: Oops, I missed the cmake files in repl.it. This is interesting that it works fine without cmake. Huh.

[ollien]

Ok, I've done some digging, but I'm unsure about a full resolution at the moment (cpr was the first and only work I did with Conan). This warning is pretty prominently displayed when you go to install cpr with Conan.

************************* WARNING: GCC OLD ABI COMPATIBILITY ***********************
 
Conan detected a GCC version > 5 but has adjusted the 'compiler.libcxx' setting to
'libstdc++' for backwards compatibility.
Your compiler is likely using the new CXX11 ABI by default (libstdc++11).

If you want Conan to use the new ABI for the default profile, run:

    $ conan profile update settings.compiler.libcxx=libstdc++11 default

Or edit '/root/.conan/profiles/default' and set compiler.libcxx=libstdc++11

************************************************************************************

Changing the ABI as it suggests seems to make everything work as expected. It even makes some level of sense if you look at the valgrind errors, given what it's failing to read.

That said, the tests that run in the CCI build system seem to pass just fine with libstdc++, if we look at some of the past runs

Short answer: there is a workaround if this ABI change is acceptable to you.

I don't have a longer answer. I'm going to file an issue in CCI about it.

[ollien]

Ah, here it is. The given CMakeLists attempts to use the new ABI, but the default Conan profile does not.

Adding

add_definitions(-D_GLIBCXX_USE_CXX11_ABI=0)

or

conan_basic_setup()

to the given CMakeLists.txt fixes this. Alternatively, set your profile as the warning indicates.
That said, I'm surprised Conan isn't adjusting this.

Sorry for the quad-comment. Mostly wanted to update based on the upstream issue.

[COM8]

Aha! Thanks for investigating @ollien

[ollien]

@COM8 Should this issue be closed, then? Seems like it's just user error in producing a CMakeLists.txt.

[COM8]

Yes. Thanks for the reminder.

[HoMiGT]

Thank you very much. I thought there was something wrong with my code. It was a compilation problem @ollien