[Clang SA] Potential memory leak when init struct field during construction

[igagis]

To reproduce:

Check out the minimal reproducer example at:
https://github.com/igagis/clang-tidy-test/blob/master/src/main.cpp

the relevant part of the code is:

struct result{
    std::shared_ptr<std::string> p;
    bool some_other_field;
};

result potential_memory_leak_2(bool arg){
    result ret{.p = std::make_shared<std::string>("Hello world!")};

    if(arg){
        throw std::runtime_error("error");
    }

    return ret;
}

run clang-tidy with all checks on.

Or just refer to the minimal reproducer's CI run:
https://github.com/igagis/clang-tidy-test/actions/runs/4231046017/jobs/7349082519

Expected result:

No false-positive potential memory leaks found

Actual result:

The following error is reported by clang-tidy:

src/main.cpp:26:1: error: Potential leak of memory pointed to by field '_M_pi' [clang-analyzer-cplusplus.NewDeleteLeaks,-warnings-as-errors]

Note

the minimal reproducer also demonstrates another false-positive, which is already reported by #55219

[llvmbot]

@llvm/issue-subscribers-clang-static-analyzer

[haoNoQ]

Looks like it's fixed in clang-15 (clang-14 for comparison), probably by the lambda capture constructor context work. There could still be problems in this area but not these particular ones.

[igagis]

well, as you can see, this is reproduced with clang-17

[haoNoQ]

Hmm. Can you make it reproduce on godbolt? Because simply selecting a fresh clang from trunk to run on your source code doesn't help. And they're, like, very fresh up there.

If not, might have something to do with the specific C++ standard library you're using, so may I ask you to attach a "preprocessed" file (made with clang -E) on which you can reproduce the problem with the same command?

(I can't reproduce it with LLVM's own libc++ on my local machine. IIRC godbolt uses GNU libstdc++ instead but still unable to reproduce the issue. Might be a specific version, or might be something else entirely. These things are usually not that hard to reproduce so it's somewhat surprising.)

[igagis]

as far as I could see, there is no clang-17 on Godbolt, so makes no sense to reproduce it there, as looks like this problem is not reproduced with older clang's.

I also cannot reproduce it on my home laptop, for some reason, but on my work laptop it is reproduced, and it is reproduced on Github actions CI in 3 environments, Debian bullseye, Ubuntu focal and Ubuntu jammy.
See here https://github.com/igagis/clang-tidy-test/actions/runs/4234360939

These builds use libstdc++, the source is first built with g++, then clang-tidy is run, I'm not sure if it uses any intermediate files, like .o.

[haoNoQ]

Actually clang-17 does not exist yet. In fact there's no clang-16 either, just release candidates (the 16.0 release date is March 7th as per llvm.org). But clang-17 wasn't even branched yet. When they say clang-17 they mean trunk. Godbolt offers nightly trunk.

One way or another, if you can extract the -E reproducer from your work machine, it'd be really helpful! Binaries like .o files aren't useful, clang-tidy works with the same things as the compiler: one .cpp file at a time, with all its includes. Preprocessing with -E causes all this information to be captured in one file which makes them super useful for reproducing such issues.

[igagis]

Here you go. Find preprocessed output in artifacts of the build:
https://github.com/igagis/clang-tidy-test/actions/runs/4243712416

Here is the link for Debian bullseye run, for example:
https://github.com/igagis/clang-tidy-test/suites/11136047782/artifacts/567896869

[damienrg]

The following code produces the warning (https://godbolt.org/z/M4eaW3cah):

#include <memory>

struct Foo
{
    std::unique_ptr<int> i;
};

void add(Foo foo)
{}

int main(int argc, const char** argv)
{
    add({std::make_unique<int>(1)});
    return 0;
}