False negatives clang-analyzer-core.StackAddressEscape when storing pointers/references in container

[chrchr-github]

#include <string>
#include <vector>

struct S { std::string* s; };
std::vector<S> f() {
    std::vector<S> v;
    {
        std::string a{ "abc" };
        v.push_back({ &a });
    }
    return v;
}

struct T { std::string& s; };
std::vector<T> g() {
    std::vector<T> v;
    {
        std::string b{ "def" };
        v.push_back({ b });
    }
    return v;
}

int main() {
    return f()[0].s->size() + g()[0].s.size();
}

https://godbolt.org/z/sMb8Ebv9j

[abhishek-kaushik22]

Sorry, what's the issue here? You are taking a reference/pointer to a local variable and the AddressStanitizer correctly points it out.

ASM generation compiler returned: 0
Execution build compiler returned: 0
Program returned: 1
=================================================================
==1==ERROR: AddressSanitizer: stack-use-after-return on address 0x72ca03809128 at pc 0x573ea7891af2 bp 0x7ffed6c87ab0 sp 0x7ffed6c87aa8
READ of size 8 at 0x72ca03809128 thread T0
    #0 0x573ea7891af1 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>::size() const /opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/15.0.1/../../../../include/c++/15.0.1/bits/basic_string.h:1086:19
    #1 0x573ea7891557 in main /app/example.cpp:21:22
    #2 0x76ca05829d8f  (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) (BuildId: 490fef8403240c91833978d494d39e537409b92e)
    #3 0x76ca05829e3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e3f) (BuildId: 490fef8403240c91833978d494d39e537409b92e)
    #4 0x573ea77a93c4 in _start (/app/output.s+0x2e3c4)

Address 0x72ca03809128 is located in stack of thread T0 at offset 40 in frame
    #0 0x573ea7890d7f in f() /app/example.cpp:5

  This frame has 3 object(s):
    [32, 64) 'a' (line 7) <== Memory access at offset 40 is inside this variable
    [96, 97) 'ref.tmp' (line 7)
    [112, 120) 'ref.tmp1' (line 8)
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-use-after-return /app/example.cpp:21:22 in main
Shadow bytes around the buggy address:
  0x72ca03808e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x72ca03808f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x72ca03808f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x72ca03809000: f1 f1 f1 f1 00 00 00 f2 f2 f2 f2 f2 f8 f8 f8 f3
  0x72ca03809080: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
=>0x72ca03809100: f5 f5 f5 f5 f5[f5]f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x72ca03809180: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x72ca03809200: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x72ca03809280: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x72ca03809300: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x72ca03809380: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==1==ABORTING

[chrchr-github]

Yes, but it should be possible to find the issues in static analysis,

[llvmbot]

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

Author: None (chrchr-github)

~~~c++ #include <string> #include <vector>

struct S { std::string* s; };
std::vector<S> f() {
std::vector<S> v;
{
std::string a{ "abc" };
v.push_back({ &a });
}
return v;
}

struct T { std::string& s; };
std::vector<T> g() {
std::vector<T> v;
{
std::string b{ "def" };
v.push_back({ b });
}
return v;
}

int main() {
return f()[0].s->size() + g()[0].s.size();
}

https://godbolt.org/z/sMb8Ebv9j
</details>

[steakhal]

Does it reproduce the FN if you avoid using the { and } initializers?
I know we have inaccurate modeling of those.
I wish someone could reduce the example futher by mocking out the std containers with homegrown stubs.
That would make it much easier to see where it goes wrong.

Thank you.

[chrchr-github]

Here's a reduction of the pointer case:

struct S { int* p; };
S f() {
    S s;
    {
        int a = 1;
        s = S(&a);
    }
    return s;
}

int main() {
    return *f().p;
}

https://godbolt.org/z/MGzohEheE

This is caught: s.p = &a; or s = S{ &a };

[chrchr-github]

Oddly, this is caught as C++ but not as C code:

struct S { int* p; };
struct S f() {
    struct S s;
    {
        int a = 1;
        s = (struct S){ &a };
    }
    return s;
}

int main() {
    return *f().p;
}

https://godbolt.org/z/Edjbsc8n9
Also not caught as C: s.p = &a;

[chrchr-github]

More container-like:

struct S { int* p; };

template <typename V>
struct T {
    V* q{};
    T() = default;
    T(T&& rhs) { q = rhs.q; rhs.q = nullptr;}
    T& operator=(T&& rhs) { q = rhs.q; rhs.q = nullptr;}
    void push_back(const V& v) { if (q == nullptr) q = new V(v); }
    ~T() { delete q; }
};

T<S> f() {
    T<S> t;
    {
        int a = 1;
        t.push_back({ &a });
    }
    return t;
}

int main() {
    return *f().q->p;
}

https://godbolt.org/z/Ps5c9b4Tn

[steakhal]

Thank you for the several proposed reproducers. They helped a lot really.
I settled with the following:

struct S { int* p; };
S top() {
    int a;
    S t(&a);
    return t;
}

This should work AFAIK the checker. So when leaving the top-level function top the checkEndFunction callback should fire, that should trigger the necessary checks in the checker. Of course, because we don't have the diagnostic, something goes sideways in the mean time.
At first glance, it shouldn't be too hard to debug. One should follow step by step from the checkEndFunction, end eventually, we should reach the iterBindings where we should see that we have a binding referring to a stack variable of the stack we are about to pop.
https://clang.llvm.org/doxygen//StackAddrEscapeChecker_8cpp_source.html

I think this is a good first issue.

Remember to use the State->dump() to get an overview of how the state looks like (including the Store, that is iterated in the iterBindings).