clang fails to destroy return value when a destructor throws

[rjmccall]

Bugzilla Link	12286
Version	trunk
OS	All
CC	@DougGregor,@seanbaxter,@mizvekov,@tavianator,@yuanfang-chen

Extended Description

If an exception is thrown after a non-POD return value is successfully constructed in the return slot but before the returning function terminates, the value in the return slot is not destroyed. This can be clearly seen in the following test case. The really easy solution would be to push an inactive destructor cleanup in the prologue and activate it whenever evaluation completes for a return value, but that wouldn't be the correct ordering of destruction as specified in [except.ctor]p1. Needs more thought.

#include <stdio.h>

struct A {
  A() { printf("creating A at %p\n", this); }
  A(const A &a) { printf("copying A at %p into %p\n", &a, this); }
  ~A() { printf("destroying A at %p\n", this); }
};

struct B {
  B() { printf("entering B\n"); }
  ~B() { printf("exiting B, throwing!\n"); throw 0; }
};

A test() {
  B b;
  return A();
}

int main() {
  try {
    printf("running\n");
    A a = test();
  } catch (int i) {
    printf("caught\n");
  }
}

[llvmbot]

This issue is giving me memory leaks, and it seems difficult to work around without undesirable interface changes.

[llvmbot]

It seems that this is still the case for all clang++ version (up until the latest 9.0.0). The behavior seems wrong as there is not strict requirement (is it?) about non-throwing destructors.

[rjmccall]

It's definitely wrong, but nobody has had time to work on it, and the fact that it's specific to throwing destructors does make it a little easier to just keep putting off. If you'd like to work on it, I have some ideas about the infrastructure work that will be necessary.

[seanbaxter]

This bug was just fixed in gcc last month, after sitting in their bug system for 13 years.

Here's a clean example:
https://godbolt.org/z/NJLU9C

I ran into it while trying to implement mandatory NRVO. That requires a closely-related EH behavior. Anyone have a clue on how to implement this? I mean, the semantics are a bit tricky.

[rjmccall]

I think it's basically the same fix for return values as for local-variable initialization. Basically, we have an object we just constructed, and we need to destroy it if one of such-and-such cleanups throws. Conveniently, the object we want to destroy is always the most recent still-living object that was constructed in this function, which means we never need to do this as anything except an EH cleanup, and so we just need the cleanup-emission code to push that EH cleanup to destroy it during the emission of all the normal cleanups that we're going to run after the return object or local variable is fully constructed.

Now, unfortunately there's some extra complexity which comes from the fact that Clang tries to emit every normal cleanup uniquely. For returns, we might have other, non-return branches threaded through those cleanups, e.g. in code like:

  {
    HasThrowingDestructor var;
    if (condition1) {
      // On this branch through var's cleanup, we should not run
      // the return-value destructor as an EH cleanup.
      break;
    } else if (condition2) {
      // On this branch through var's cleanup, we should run it.
      return std::string("help");
    }
    // On the fall-through branch when leaving the scope, we should not run it.
  }

I think the same thing can happen with local variables because of statement-expressions, unfortunately:

  std::string var = ({ if (condition) break; "help" });

And, unfortunately, there's a very silly situation where a cleanup can have to worry about both, although I think dynamically they can't coincide.

  // The normal cleanup for the `HasThrowingDestructor` temporary is
  // active during both the return branch in the statement-expression
  // and the end-of-initialization branch for `var`.
  std::string var = HasThrowingDestructor().buildString(
                      ({ if (condition) return std::string("returned"); 
                         "value" }));

So to handle this right, I think you need three things.

1. We need to track three bits on every cleanup:

• whether it was active during a return branch
• whether it was active during an end-of-initialization branch
• whether it was active during a branch that wasn't either of the above

2. We need to be able to tell the cleanup manager that a branch through cleanups is happening for one of those two special reasons.

3. We need to make the cleanup manager capable of both:

• pushing a destruction EH cleanup for the return value during the emission of a cleanup if it was active during a return branch and

• pushing a destruction EH cleanup for the current initialized address (which can be maintained via some SaveAndRestore gadget during the emission of an initializer full-expression) during the emission of a cleanup if it was active during an end-of-initialization.

And those EH cleanups need to be conditional if the cleanup being emitted wasn't solely active during the appropriate kind of branch, and setting up that condition flag might be really difficult.

[rjmccall]

Honestly, it's things like this that make me wonder if we should just emit cleanups non-uniquely. That has a serious code-size cost but is much simpler.

[seanbaxter]

Honestly, it's things like this that make me wonder if we should just emit
cleanups non-uniquely. That has a serious code-size cost but is much
simpler.

You only need to add a non-unique cleanup for the return object (for both NRVO and URVO cases) from the landing pad for each potentially-throwing dtor call. After executing that return object's dtor, you'd branch back into the chain of unique dtor calls for the remaining initialized objects.

Conveniently, the object we want to destroy is always the most recent still-living object that was constructed in this function.

This is true only for the URVO case. For NRVO, which is the return object may be initialized before the object with the throwing dtor:

a_t a("result object");  // initialize a into the sret
b_t b("throwing dtor");
if(cond)
  return a;  // an nrvo scenario.

In this case, we can (I think) get by with the unique cleanup code for a, and can call it unconditionally from b's EH cleanup code.

b_t b("throwing dtor");
a_t a("result object");  // initialize a into the sret
if(cond)
  return a;  // an nrvo scenario.

In this case, the result object's declaration is in the potential scope of the potentially throwing dtor's object, so b's landing pad would have to conditionally cleanup the result object before branching to the remaining unique cleanup calls.

To implement normal destruction of NRVO I alloca a single bit to hold the returned state of the return object. It's cleared when the function is entered. After the named return object is initialized, it's set to 1. When the return statement that returns it is encountered, all that codegen does is clear that flag and do return (void) control flow. When the normal dtor chain is executed, it sees that the return object has a cleared flag, and therefore skips over its cleanup and continues to the prior objects.

I believe we can handle EH cleanup with an additional flag: one that is set after the return object's ctor finishes, and is not cleared by the return statement. Then we amend the behavior for the normal path to only cleanup the return object if the first flag is cleared and the second is set. The EH code cleans up if the first flag (is initialized) is set, and ignores the second flag (the one cleared by return).

a_t a("return object"); // initialized into sret
try {
  b_t b("throwing object"); // ~b throws
  return a;

  // throw!

} catch(...) {
  // Catch's ~b's exception.
  // a must still be initialized, but we'll need to 
  // return it YET AGAIN, which should be another 
  // no-op.
  return a;
}

There are weird things like this, where catching a dtor exception effectively un-returns a return object. That object was constructed in the sret, and since it was declared before b, b's EH doesn't clean it up, but the catch clause takes us out of the EH world and into the normal, so I guess we have to be smart enough to clear the flag indicating that a was returned, then set it again at the second return statement.

I'm not eager to implement this stuff. I can't even hold it in my mind. But I suspect the committee people are going to be giving it greater scrutiny now that mandatory NRVO is being reviewed.

[rjmccall]

Honestly, it's things like this that make me wonder if we should just emit
cleanups non-uniquely. That has a serious code-size cost but is much
simpler.

You only need to add a non-unique cleanup for the return object (for both
NRVO and URVO cases) from the landing pad for each potentially-throwing dtor
call. After executing that return object's dtor, you'd branch back into the
chain of unique dtor calls for the remaining initialized objects.

Yes, but that's not the part of uniqueness that's an issue. It's the uniqueness of the potentially-throwing dtor call that's a problem.

Conveniently, the object we want to destroy is always the most recent still-living object that was constructed in this function.

This is true only for the URVO case. For NRVO, which is the return object
may be initialized before the object with the throwing dtor:

Ah, right, of course. This needs almost totally different handling.

I believe we can handle EH cleanup with an additional flag: one that is set
after the return object's ctor finishes, and is not cleared by the return
statement. Then we amend the behavior for the normal path to only cleanup
the return object if the first flag is cleared and the second is set. The EH
code cleans up if the first flag (is initialized) is set, and ignores the
second flag (the one cleared by return).

We could push a second cleanup for NRVO variables just for this purpose and track it on the cleanup manager. But the trick is that cleanups outside that cleanup still need the floating-return-value-cleanup treatment.

[llvmbot]

When a destructor throws exception, memory leaks occur. In order to rectify this, we can use shared pointers. Shared pointer will help in destroying the resource when it goes out of the scope. So, there will be no memory leaks.
(Use shared pointer in try block).

[llvmbot]

@llvm/issue-subscribers-clang-codegen

| | | | --- | --- | | Bugzilla Link | [12286](https://llvm.org/bz12286) | | Version | trunk | | OS | All | | CC | @DougGregor,@seanbaxter,@mizvekov,@tavianator,@yuanfang-chen |

Extended Description

If an exception is thrown after a non-POD return value is successfully constructed in the return slot but before the returning function terminates, the value in the return slot is not destroyed. This can be clearly seen in the following test case. The really easy solution would be to push an inactive destructor cleanup in the prologue and activate it whenever evaluation completes for a return value, but that wouldn't be the correct ordering of destruction as specified in [except.ctor]p1. Needs more thought.

#include <stdio.h>

struct A {
  A() { printf("creating A at %p\n", this); }
  A(const A &a) { printf("copying A at %p into %p\n", &a, this); }
  ~A() { printf("destroying A at %p\n", this); }
};

struct B {
  B() { printf("entering B\n"); }
  ~B() { printf("exiting B, throwing!\n"); throw 0; }
};

A test() {
  B b;
  return A();
}

int main() {
  try {
    printf("running\n");
    A a = test();
  } catch (int i) {
    printf("caught\n");
  }
}