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

[David Chisnall]

On 21 Nov 2017, at 16:13, Lobron, David <dlobron@akamai.com> wrote:
> 
>> This looks like it’s trying to all a version with C++ name mangling.  Try 
>> sticking an extern “C” { } around the #includes.
> 
> Thanks, David.  That extern statement did not fix the compilation problem, 
> but I was able to simplify things by reverting to my original test program 
> that simply throws a C++ std::exception in code compiled with a .mm suffix.  
> That program now builds and runs correctly, whereas previously, it crashed.  
> So I think the changes we made do fix the problem.
> 
> Unfortunately, my main program is still crashing with a NULL exception.  I'm 
> now wondering if there's something wrong with my build command, or maybe with 
> the runtime flags I'm passing to my main program.

You will need to make sure that every stack frame that may have C++ exceptions 
thrown through it is compiled with -fobjc-runtime=gnustep-1.8 (or 1.7, I forget 
exactly when I fixed this).  The old GCC ABI corrupts foreign exceptions when 
they are thrown through Objective-C frames.  

> I ran nm on the test program to see what exception personality it uses:
> 
> $ nm -C CXXException_mm|grep -i except
>                 U __cxa_allocate_exception@@CXXABI_1.3
> 0000000000400ea4 r GCC_except_table0
>                 U std::exception::~exception()@@GLIBCXX_3.4
> 00000000006020d0 V typeinfo for std::exception@@GLIBCXX_3.4
> 00000000006020a0 V vtable for std::exception@@GLIBCXX_3.4
> 
> I checked for those strings in my main program, and the result was similar, 
> although not identical:
> 
> $ nm -C obj/mapmaker|grep __cxa_allocate_exception
>                 U __cxa_allocate_exception@@CXXABI_1.3
> (ALSI8)dlobron@bos-lps80:~/build/clangport/akamai/mapmaker$ nm -C 
> obj/mapmaker|grep std::exception   
>                 U std::exception::~exception()@@GLIBCXX_3.4
>                 U typeinfo for std::exception@@GLIBCXX_3.4
> 
> The only difference here is that the non-working main program doesn't have 
> "vtable for std::exception".  Could that be the source of the problem?  Or 
> could this be a runtime or compile-time difference in my code?

If it doesn’t have a reference to the vtable for std::exception then that 
implies that it isn’t actually allocating a std::exception, which is a little 
bit surprising.

David