std::rethrow_exception and catch as const char*& gives invalid memory address

[tonttu]

Captured rethrown string literal seems to point to an unallocated memory location if capturing the string by reference.

If I change it to catch by value, or throw anything else except const char*, the code seems to work fine. It also compiles and runs correctly using gcc.

The problem with clang happens on both amd64 Linux and M1 macOS.

#include <exception>
#include <cstdio>

int main() {
  std::exception_ptr err;
  try {
    throw "foo";
  } catch (...) {
    err = std::current_exception();
  }

  using E = const char *;
  try {
    std::rethrow_exception(err);
  } catch (E& err) {
    printf("%s\n", err);
  }
}

The application prints (null).

On Linux Valgrind complains:

==23939== Invalid read of size 8
==23939==    at 0x400B53: main (in ./a.out)
==23939==  Address 0x5b7fdc0 is 0 bytes after a block of size 112 alloc'd
==23939==    at 0x4C31B0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23939==    by 0x4ECF9AD: __cxa_allocate_dependent_exception (eh_alloc.cc:315)
==23939==    by 0x4ED0A82: std::rethrow_exception(std::__exception_ptr::exception_ptr) (eh_ptr.cc:229)
==23939==    by 0x400B01: main (in ./a.out)

[tonttu]

@EugeneZelenko I don't think libc++ is right label for this issue, since I'm using libstdc++ on Linux and libc++ on mac and the issue happens on both.

Additionally if I compile the code using gcc with libc++, the code works fine.

[deepakcse87]

@tonttu , Is this similar to this issue reported here on mac arm64 and ios? https://bugs.chromium.org/p/chromium/issues/detail?id=1326793

[llvmbot]

@llvm/issue-subscribers-clang-codegen

[jyknight]

This doesn't appear to be related to string (or even char) literals, rather, catching a reference to a pointer to a primitive type.

I'd say it appears to be due to the code here:

llvm-project/clang/lib/CodeGen/ItaniumCXXABI.cpp

Line 4448 in 69cd741

// When catching by reference, generally we should just ignore

I haven't dug in exactly what's going on in that code...

Here's another version of the repro:

#include <exception>
#include <cstdio>

struct X {int x;};
X x;

#ifdef BROKEN
#define T char
#else
#define T X
#endif

std::exception_ptr err;
int main() {
  try {
    printf("addr1 %p\n", &x);
    throw (const T *)&x;
  } catch (...) {
    err = std::current_exception();
  }

  try {
    std::rethrow_exception(err);
  } catch (const T*& errs) {
    printf("addr2 %p\n", errs);
  }
}

[jyknight]

Wow. If you attempt to catch a pointer by reference (e.g. catch (T*&ref)), everyone gets it wrong.

• In GCC, it basically just acts as if you caught the pointer by value (ignoring the reference). Changes you attempt to make to the pointer value are lost. E.g. if you ref = 0; throw; and some higher frame catches it again, they should see the pointer value being 0, not the original value. But you don't. https://gcc.gnu.org/PR99858
• In Clang's Itanium EH handling, it does as GCC does when T is a struct. But, when T is a primitive type, it tries to hack around this issue, so you can mutate the pointer. Unfortunately, this hack rummages around in the internals of the exception object -- which breaks std::rethrow_exception, as per this bug.
• In MSVC, it is possible to mutate the pointer for any type....BUT, it mishandles adjusted base-pointers! E.g. in struct A {char a}; struct B {char b;}; struct C : public A, public B {}; B is at C+1. So, if you throw a C* and catch a B*, the resulting pointer should be offset by 1 from what was thrown. In MSVC, if you throw a C* and catch a B*&, it adjusts the reference address by 1!
• Clang targeting Windows acts like MSVC.

What a mess...

Ultimately, as a comment in Clang's code says "the problem is that we have no way to tell the personality function that we're catching by reference, so if we're catching a pointer, __cxa_begin_catch will actually return that pointer by value."

This violates the language semantics in two ways:

1. If you have struct A : public B {};, and throw a B*, that should not be caught by catch (A*& ptrref) (though it would via catch (A* ptr)). But, it will be.

2. Assigning to the pointer through the reference ought to be visible to other catch blocks if we rethrow the exception after the mutation. But it won't be.

Unfortunately, there's nothing we can actually do about that within the current (long-standing) Itanium EH ABI. So, I'd propose to remove the broken hack that's in Clang, and make Clang also consistently act as if it's catching the pointer by value instead of reference -- like GCC does. That will have the impact that the following code (from the GCC bug) will now act as if you caught the pointer by value, rather than by reference, and the second catch will not see the mutation of ptr to 0.

int main() try {
    try {
        throw (void*)1;
    } catch (void*& ptr) {
        printf("%p %p\n", ptr, &ptr);
        ptr = nullptr;
        throw;
    }
} catch (void*& ptr) {
    printf("%p %p\n", ptr, &ptr);
}

And, the test demonstrating the MSVC issue (&ptr is offset by 1, rather than ptr getting offset by 1!):

struct A {char x;};
struct B {char y;};
struct C : public A, public B {};

int main() try {
    try {
        throw (C*)1;
    } catch (C*& ptr) {
        printf("%p %p\n", ptr, &ptr);
        ptr = nullptr;
        throw;
    }
} catch (B*& ptr) {
    printf("%p %p\n", ptr, &ptr);
}

[jyknight]

Proposed fix: https://reviews.llvm.org/D127545