Crash occurs when catching std::exception in Objective-C++ code compiled with clang on Linux and using libobjc2

[Lobron, David]

Hello GNUstep,

I opened a bug with clang/llvm a few months ago when I found that Objective-C++ 
programs compiled with clang on Linux were crashing with a segmentation fault 
when the code attempted to catch a std::exception.  The crash only occurred 
when the code was compiled as Objective-C++ (i.e., with a suffix of .mm).  When 
compiled as C++, with a .cc suffix, the code works correctly.  The code to 
reproduce the bug is very simple and pure C++:

#include <iostream>

using namespace std;

int main(int argc, char *argv[]) {
  try {
    throw exception();
  } catch (exception &e) {
  }

  return 0;
}

I worked on this with an llvm developer, and he reported the following:

"I've investigated the issue further and discovered that the problem is with 
personality routine. For C++ in my case it was 
__cxxabiv1::__gxx_personality_v0. It returned _URC_HANDLER_FOUND and correctly 
prepared everything to land in the catch block.

For ObjC++ it was __gnu_objc_personality_v0 () from 
/usr/lib/x86_64-linux-gnu/libobjc.so.4. In my case it returned 
_URC_CONTINUE_UNWIND, so the exception wasn't caught in `main` and it caused 
SIGABRT as any uncaught exception does. Personality routine is also responsible 
for setting exception object for the catch block so it might be causing NULL 
exception object you are observing."

In my own tests, I'm using GNUStep libobjc2, version 1.8.1, which produces a 
shared library called libobjc.so.4.6.  My C++ binary has a different 
personality from the ObjC++ binary:

C++ (works): __gxx_personality_v0@@CXXABI_1.3
ObjC++ (crashes): __gnu_objc_personality_v0

I checked for the string "personality" in libobjc2.so.4.6 using nm, and found 
the following matching symbols:

000000000022e590 d DW.ref.__gcc_personality_v0
000000000022ff08 d DW.ref.__gnustep_objc_personality_v0
                 U __gcc_personality_v0@@GCC_3.3.1
00000000000126b0 T __gnu_objc_personality_v0
0000000000012d20 T __gnustep_objc_personality_v0
0000000000012d60 T __gnustep_objcxx_personality_v0
                 w __gxx_personality_v0
00000000000126f0 t internal_objc_personality

I'm a bit suspicious of the "__gcc_personality_v0@@GCC_3.3.1" line, since I'm 
compiling with clang rather than gcc.  But that might be a red herring.

The llvm/clang developers suggested I get in touch with GNUstep to see if this 
is a known issue.  Has anyone seen this behavior before?

Thanks,

David