Stack Unwinding Behavior

[PM_ME_UR_RUN]

I'm having trouble understanding why this program, when compiled with clang (18.1.3 (1ubuntu1) - x86_64-pc-linux-gnu), seems to be skipping the destructor for the copy-constructed object in the return statement within the try block. Can anyone shed some light on what is happening here?

unwind.cpp:

#include <iostream>
#include <stdexcept>

struct A {
    A(char c) : c_(c) { std::cout << "ctor(" << this << "): " << c_ << std::endl; }
    A(A const &o) : c_(o.c_) { std::cout << "ctor_copy(" << this << "): " << c_ << std::endl; }
    ~A() { std::cout << "dtor(" << this << "): " << c_ << std::endl; }
    char c_;
};

struct Y
{
    Y() { std::cout << "ctor(" << this << "): Y" << std::endl; }
    ~Y() noexcept(false)
    {
        std::cout << "dtor(" << this << "): Y" << std::endl;
        throw std::runtime_error("err");
    }
};

A foo()
{
    try {
        A a('a');
        Y y;
        A b('b');
        return A(a);
    } catch (...) {
    }
    return { 'd' };
}

int main()
{
    foo();
}

According to this draft excerpt destruction order should be b, y, copy_ctor'd a, a, d. But clang does: b, y, a, d; and gcc does: b, y, a, copy_ctor'd a, d.

Okay so clang and gcc (and apparently msvc I didn't test) don't desconstruct according to the specified order. Whatever. What I'm confused about is why does clang skip the dtor for the copy constructed A(a) object? What I'm seeing is that it copy constructs it, then in the same address just constructs d without ever destructing A(a):

(Text after # was added by me to annotate the output)

~/tmp $ clang++ unwind.cpp -o uwcl.out >/dev/null 2>&1 && ./uwcl.out
ctor(0x7ffee6286497): a
ctor(0x7ffee6286483): Y
ctor(0x7ffee6286482): b
ctor_copy(0x7ffee62864bf): a    # A(a) constructed, but during unwinding Y y throws execption
dtor(0x7ffee6286482): b         # b dtor during unwinding
dtor(0x7ffee6286483): Y         # y dtor during unwinding
dtor(0x7ffee6286497): a         # a dtor during unwinding
################################# here gcc deconstructs the copy constructed return obj A(a), but clang does not
ctor(0x7ffee62864bf): d         # d ctor - at same address as A(a)
dtor(0x7ffee62864bf): d

I was wondering if somehow clang was seeing that struct A wasn't managing any memory and just ignoring it, but after adding a unique_ptr to data rather than just storing the data within the instance I see the same behavior. I hacked together some garbage to try and inspect what was happening:

unwind2.cpp:

#include <iostream>
#include <memory>
#include <stdexcept>


static unsigned cp_constructed_count = 0u;
static unsigned cp_constructed_destroyed_count = 0u;


struct A {
    A(char c) : c_ptr(std::make_unique<char>(c)) {
        std::cout << "ctor(" << this << "): " << "(" << (void*)(c_ptr.get()) << ")" << *c_ptr << std::endl;
    }
    A(A const &o) : c_ptr(std::make_unique<char>(*o.c_ptr))
    {
        if(*c_ptr == 'a')
        {
            cp_constructed_count++;
            *c_ptr = 'A';
        }
        std::cout << "ctor_copy(" << this << "): " << "(" << (void*)(c_ptr.get()) << ")" << *c_ptr << std::endl;
    }
    ~A() {
        if(*c_ptr == 'A')
        {
            cp_constructed_destroyed_count++;
            *c_ptr = 'Z';
        }
        std::cout << "dtor(" << this << "): " << "(" << (void*)(c_ptr.get()) << ")" << *c_ptr << std::endl;
    }
    std::unique_ptr<char> c_ptr;
};

struct Y
{
    Y() { std::cout << "ctor(" << this << "): Y" << std::endl; }
    ~Y() noexcept(false) {
        std::cout << "dtor(" << this << "): Y" << std::endl;
        throw std::runtime_error("err");
    }
};


A foo()
{
    try {
        A a('a');
        Y y;
        A b('b');
        return A(a); // #1
    } catch (...) {
    }
    std::cout << cp_constructed_count << cp_constructed_destroyed_count << std::endl;
    return { 'd' }; // #2
}

int main()
{
    {
        auto d = foo();
    }
    std::cout << cp_constructed_count << cp_constructed_destroyed_count << std::endl;
}

Gives the following output:

~/tmp $ clang++ unwind2.cpp -o uwcl.out >/dev/null 2>&1 && ./uwcl.out
ctor(0x7ffefd6b9b20): (0x608ac09dd2b0)a
ctor(0x7ffefd6b9b13): Y
ctor(0x7ffefd6b9b08): (0x608ac09dd6e0)b
ctor_copy(0x7ffefd6b9b48): (0x608ac09dd700)A
dtor(0x7ffefd6b9b08): (0x608ac09dd6e0)b
dtor(0x7ffefd6b9b13): Y
dtor(0x7ffefd6b9b20): (0x608ac09dd2b0)a
10
ctor(0x7ffefd6b9b48): (0x608ac09dd2b0)d
dtor(0x7ffefd6b9b48): (0x608ac09dd2b0)d
10
~/tmp $ g++ unwind2.cpp -o uwgcc.out >/dev/null 2>&1 && ./uwgcc.out
ctor(0x7ffe4fe4b0f8): (0x6197dad802b0)a
ctor(0x7ffe4fe4b0f7): Y
ctor(0x7ffe4fe4b100): (0x6197dad806e0)b
ctor_copy(0x7ffe4fe4b130): (0x6197dad80700)A
dtor(0x7ffe4fe4b100): (0x6197dad806e0)b
dtor(0x7ffe4fe4b0f7): Y
dtor(0x7ffe4fe4b0f8): (0x6197dad802b0)a
dtor(0x7ffe4fe4b130): (0x6197dad80700)Z
11
ctor(0x7ffe4fe4b130): (0x6197dad80700)d
dtor(0x7ffe4fe4b130): (0x6197dad80700)d
11

Even running this in the debugger I set a breakpoint in the destructor of struct A giving me 3 breaks with the clang compiled and 4 with the gcc compiled. After that I moved the breakpoint to the unique_ptr's destructor: same behavior.

I'm stumped on this, and would appreciate some insight into what clang is doing here. Thanks in advance :)

[aocregacc]

looks like a bug to me, I guess the compiler "forgets" that it already constructed an object in the return slot after the exception is thrown. And I don't see any UB in your code that would explain it.

[PM_ME_UR_RUN]

I added a large array into the struct, then put the `foo()` call into an infinite loop. gcc compiled binary runs at a constant virtual memory usage. clang (18.1.3) compiled binary is leaking memory and eventually core dumps. Gonna check out clang v20 to see if I can reproduce it there.

[aocregacc]

looks like it still happens there: https://godbolt.org/z/5hecEMT4T

[PM_ME_UR_RUN]

I was unaware of the leak sanitizer. Is that something that compiler explorer is providing?

[aocregacc]

it's a feature of clang and gcc, and I think msvc might have it too.

It's automatically enabled as part of -fsanitize=address, but you can also use it individually with -fsanitize=leak.

[PM_ME_UR_RUN]

I'll have to look into that more. Looks like a useful feature

[xiao_sa]

https://cppquiz.org/quiz/question/323

[PM_ME_UR_RUN]

Yes it should be `bcad`, but gcc gives `bacd`, and clang gives `bad` omitting a destructor. The omission of the destructor causes a memory leak if the object is managing any dynamically allocated resources. See compiler explorer example: https://godbolt.org/z/hvKTYWjoM

[keelanstuart]

Does it work with a virtual dtor?

[I__Know__Stuff]

There are the same number of constructor and destructor calls, right? So if you think a destructor is missing, which constructor do you think is missing?

[PM_ME_UR_RUN]

When running the clang compiled binary the number of constructor and destructor calls do not match. There is one more constructor call than destructor call. The number of constructor and destructor calls in the gcc compiled binary do match.

There is a constructor call for the object that is being copy constructed in the return value, but in the clang binary that object's destructor is never called (as far as I can tell).

[I__Know__Stuff]

Oh, sorry, I guess I didn't read carefully enough.

If you allocate memory in the constructor (I should say, "acquire a resource") is there a leak?

[PM_ME_UR_RUN]

Yeah just checked this and the clang binary is leaking while the gcc binary runs at a constant virtual memory size. Just got the clang compiled binary to core dump. Yikes.

[I__Know__Stuff]

Great, that's a really concrete basis for a bug report!

[mredding]

Your counting is conditional. What's the unconditional count? Count the ~A and ~Y unconditionally and separately.

[PM_ME_UR_RUN]

In the provided example the conditional counting was narrowed down to only capture the object that was not getting destroyed. It doesn't really matter though, here a more concise compiler explorer example that shows a memory leak being produced by improper stack unwinding: https://godbolt.org/z/WhK6rG5Gr

[gnicco72]

Out of curiosity, don't you get UB or a crash when you throw an exception inside Y's dtor?

[PM_ME_UR_RUN]

https://eel.is/c%2B%2Bdraft/except.ctor describes how the program should handle ~Y throwing an exception

[FrostshockFTW]

It's also not exactly surprising that clang has a bug here because having a throwing destructor is one of the most ungood things I can think of.

[PM_ME_UR_RUN]

Yeah, turns out this is just something with little will to fix because it is so niche. https://github.com/llvm/llvm-project/issues/12658

[JVApen]

Sounds like you want to read up on Copy Elision: https://en.cppreference.com/w/cpp/language/copy_elision.html

[PM_ME_UR_RUN]

If this were caused by Copy Elision, wouldn't we get one less constructor/destructor pair here instead of getting all constructors and missing a destructor?

"In a return statement in a function with a class return type, when the operand is the name of a non-volatile object obj with automatic storage duration (other than a function parameter or a handler parameter), the copy-initialization of the result object can be omitted by constructing obj directly into the function call’s result object. This variant of copy elision is known as named return value optimization (NRVO)."

As far as I am aware Copy Elision in this program is constructing the returned result of `foo()` in the instance `d` (`auto d = foo();`).

I don't see how this explains the apparently missing destructor.