Problems throwing and catching exceptions on OS X with -fno-rtti

Question

The issue is somewhat similar to this question but the accepted answer does not really propose a solution or workaround.

In our project, we have a dylib and the main executalble. The dylib is compiled with -fno-rtti, while the executable does use RTTI. The problem happens when an exception (e.g. std::bad_alloc) is thrown from the dylib and is caught in the exe.

(Before you yell "exceptions need RTTI so you must have it on!", please note that the RTTI necessary for exceptions is always generated regardless of the -frtti or -fno-rtti setting. This is actually documented in the -fno-rtti flag description. The issue on OS X is that it's not generated in the same way)

After some investigation, the following was discovered:

In the dylib (-fno-rtti), there is a local copy of the exception's RTTI structures; in particular, the __ZTISt9bad_alloc symbol (typeinfo for std::bad_alloc).
The exe (-frtti) imports the typeinfo symbol from libstdc++.6.dylib and does not have a local copy

Since the exception handling code relies on comparing typeinfo pointers to determine exception match, the matching fails, and only the catch(...) succeeds.

So far I see the following options:

1) compile everything, or at least the files that throw and catch exceptions, with -frtti. This is doable but I don't like the idea of generating RTTI for everything even if we don't use it; and the list of files which work with exceptions is prone to get stale.

2) when linking the dylib, somehow make the linker throw away the weak exception definition from the object file and use the one from libstdc++.6.dylib. So far I was not successful.

3) ???

I made a small test illustrating the problem.

--- throw.cpp ---
#include <iostream>

#if defined(__GNUC__)
#define EXPORT __attribute__((visibility("default")))
#else
#define EXPORT __declspec(dllexport)
#endif

EXPORT void dothrow ()
{
   std::cout << "before throw" << std::endl;
   throw std::bad_alloc();
}

--- main.cpp ---
#include <stdio.h>
#include <iostream>

#if defined(__GNUC__)
#define IMPORT extern
#else
#define IMPORT __declspec(dllimport)
#endif

IMPORT void dothrow ();

int main (void) {
 try {
   std::cout << "trying lib->main exception" << std::endl;
   dothrow ();
 }
 catch ( const std::bad_alloc& )
 {
   std::cout << "caught bad_alloc in main - good." << std::endl;
 }
 catch (...)
 {
   std::cout << "caught ... in main - bad!" << std::endl;
 }
}

--- makefile ---
# for main exe
CFLAGS_RTTI=-m32 -frtti -fvisibility=hidden -fvisibility-inlines-hidden -shared-libgcc -funwind-tables
# for dylib
CFLAGS_NORTTI=-m32 -fno-rtti -fvisibility=hidden -fvisibility-inlines-hidden -shared-libgcc
# for linking; some switches which don't help
CLFLAGS=-Wl,-why_live,-warn_commons,-weak_reference_mismatches,error,-commons,error

all: test

test: libThrow.dylib main.o
    g++ $(CFLAGS_RTTI) -o test main.o -lthrow -L./ $(CLFLAGS)

main.o: main.cpp
    g++ $(CFLAGS_RTTI) -c -o main.o main.cpp

throw.o: throw.cpp
    g++ $(CFLAGS_NORTTI) -c -o throw.o throw.cpp

libThrow.dylib: throw.o
    g++ $(CFLAGS_NORTTI) -dynamiclib -o libThrow.dylib throw.o

clean:
    rm test main.o throw.o

Running:

$ ./test
trying lib->main exception
before throw
caught ... in main - bad!

Symbols of the files involved:

$ nm -m throw.o | grep bad_alloc
000001be (__TEXT,__textcoal_nt) weak private external __ZNSt9bad_allocC1Ev
000001be (__TEXT,__textcoal_nt) weak private external __ZNSt9bad_allocC1Ev
00000300 (__TEXT,__eh_frame) weak private external __ZNSt9bad_allocC1Ev.eh
         (undefined) external __ZNSt9bad_allocD1Ev
00000290 (__DATA,__const_coal) weak external __ZTISt9bad_alloc
000002a4 (__TEXT,__const_coal) weak external __ZTSSt9bad_alloc
         (undefined) external __ZTVSt9bad_alloc

$ nm -m libThrow.dylib | grep bad_alloc
00000ce6 (__TEXT,__text) non-external __ZNSt9bad_allocC1Ev
         (undefined) external __ZNSt9bad_allocD1Ev (from libstdc++)
00001050 (__DATA,__const) weak external __ZTISt9bad_alloc
00000e05 (__TEXT,__const) weak external __ZTSSt9bad_alloc
         (undefined) external __ZTVSt9bad_alloc (from libstdc++)

$ nm -m main.o | grep bad_alloc
         (undefined) external __ZTISt9bad_alloc

$ nm -m test | grep bad_alloc
         (undefined) external __ZTISt9bad_alloc (from libstdc++)

Note: similar compilation options on Linux and Windows works fine. I can throw exceptions from a shared object/dll and catch them in the main exe, even if they're compiled with different -frtti/-fno-rtti options.

EDIT: here's how I ended up solving it for the specific case of bad_alloc:

#if defined(__GLIBCXX__) || defined(_LIBCPP_VERSION)
 #define throw_nomem std::__throw_bad_alloc
#else
 #define throw_nomem throw std::bad_alloc
#endif

EXPORT void dothrow ()
{
   std::cout << "before throw" << std::endl;
   throw_nomem();
}

The function __throw_bad_alloc is imported from libstdc++.6.dylib and so always throws a correct type.

(1) would seem at-least feasible if you had a way of squelching rtti for everything you don't need it for, such as a platform-dependant attribute, or turning it on in said-same manner. Interesting problem. I avoid throwing exceptions across dylibs for such reasons, but that may not be an option for you. — WhozCraig
Can you even compile code that contains a throw statement with -fno-rtti? My GCC (admittedly not OSX, but still) doesn't let me do that at all (immediately bails out with an error), much to my grief. Also, it adds RTTI for every darn type in any translation unit whether the type may be thrown or not. — Damon
@Damon: yes, it works for me in GCC 4.2 and 4.4 on Linux (don't have any newer ones to test right now). — Igor Skochinsky
What I don't understand is why throw would seemingly use the weak __ZTISt9bad_alloc symbol in libThrow.dylib when there's a strong version of it to use (albeit indirect from libstdc++abi) in libstdc++.dylib which is probably being used by the catch. This seems like a "bug" (or at least a "quirk") with ld to me. Is that what seems to be going on? — Turix

abyss.7 abyss.7 · Accepted Answer · 2014-03-03T06:02:16

You can simply move all your "throw exceptions" infrastructure to the helper library with -frtti enabled - and link it to other stuff. Without actual code it's hard to tell, if this decomposition is possible or not.

Here is some sample code:

// Thrower.cc
void DoThrow() {
  throw std::bad_alloc;
}

// LibraryNoRTTI.cc
void f() {
  DoThrow();
}

// main.cc
int main() {
  try {
    f();
  }
  catch(std::bad_alloc&) {}
  return 0;
}

The simplest way is to move all your throw invocations to the separate functions with appropriate types, like: throw std::logical_error("message"); goes to void ThrowLogicError(const std::string& message) { ... }

If there is a problem with encapsulation (private exception classes), then you may make friends with throwing functions.

If you still want to use (throw/catch) exceptions inside the non-rtti library, then you have to make separation between internal exceptions and exceptions used in your library API.

The good way is to use native C++ throw-catch for internal purposes - and then rethrow some exceptions, using rtti-based library functions, to the outside - according to your interface:

// Thrower.cc
void Rethrow(const std::exception& e) {
  throw e;
}

// LibraryNoRTTI.cc
namespace {

void internal_stuff() {
  throw std::logical_error("something goes wrong!");
}

}  // namespace

// You even may explicitly specify the thrown exceptions in declaration:
void f() throw(std::logical_error) {
  try {
    internal_stuff();
  }
  catch(std::exception& e) {
    Rethrow(std::logical_error(std::string("Internal error: ") + e.what());
  }
}

Problems throwing and catching exceptions on OS X with -fno-rtti

3 Answers