Debugging 'terminate called after throwing an instance of ...', when the exception _should_ have been caught

Question

I'm debugging an issue which only seems to happen on Solaris (we test on Windows, Linux, OSX, Solaris, HP-UX, and AIX).

Our code throws an exception (which is totally expected), and this results in the 'terminate called after throwing an instance of ...' message being printed, and the process being terminated.

(dbx) where -h
current thread: t@1
dbx: forward reference `Connection' not defined, see `help forwardref'
  [1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xffbffeff, 0x0), at 0xff2ce364
  [2] raise(0x6, 0x0, 0x0, 0xff2ad954, 0xffffffff, 0x6), at 0xff267958
  [3] abort(0x132cb0, 0x1, 0xff122f38, 0xedbe0, 0xff333558, 0x0), at 0xff242910
=>[4] __gnu_cxx::__verbose_terminate_handler(), line 95 in "vterminate.cc"
  [5] __cxxabiv1::__terminate(handler = 0xff125098 = &__gnu_cxx::__verbose_terminate_handler()), line 47 in "eh_terminate.cc"
  [6] std::terminate(), line 57 in "eh_terminate.cc"
  [7] __cxa_throw(obj = 0x132cf8, tinfo = 0xfef2bf2c, dest = 0xfe204240 = &Simba::Support::ErrorException::~ErrorException()), line 87 in "eh_throw.cc"
  [8] Simba::ODBC::ConnectionAttributes::SetAttribute(this = 0x12a060, in_attribute = <value unavailable>, in_value = 0x132c78, in_length = -3), line 299 in "ConnectionAttributes.cpp"

Simba::Support::ErrorException is the type the message complains about, and we are throwing an instance of it on line 299 in ConnectionAttributes.cpp, but as far as I know, that shouldn't cause std::terminate() to be thrown, because:

As far as I can tell, this isn't being thrown from a destructor during stack unwinding prompted by a prior exception (I added tracing into the exception type's constructor, and it's only called once before the crash)
The current thread's stack has at least one frame with a catch (Simba::Support::ErrorException&) on it (and that same frame has a catch (...) too, just to be sure), with probably others above it that should catch the exception.

What other reasons could there be for this? Am I missing something with my logic?

Given that it's only happening on Solaris, I'm thinking some issue in the runtime?

Edit: Some more details

uname -a output on the machine: SunOS b3-sol10spr-01 5.10 Generic_147440-01 sun4v sparc sun4v
We're building w/ GCC 4.9.2
This is happening on a SPARC box, but we've had other issues related to exceptions on Solaris x86 before: Crash caused by invalid exception unwinding?
Flags used during compilation of the driver: -DSIZEOF_LONG_INT=4 -DSQL_WCHART_CONVERT -DHAVE_LONG_LONG -m32 -fPIC -pthread -Wall -Wno-unknown-pragmas -DSIMBA -D_REENTRANT -DCLUNIX -DNDEBUG -D_POSIX_PTHREAD_SEMANTICS -O0 -g -D_DEBUG
Flags used during linking of the driver: -DSIMBA -D_REENTRANT -m32 -fPIC -pthread -Wall -Wno-unknown-pragmas -O1 -g -shared -mimpure-text -static-libgcc -Wl,-M,exports_Solaris.map (skipped a bunch of -lxxx)

LDD output for shared library (which houses the offending code)

        libicudata_sb32.so.53 =>         /bamboo/Adhoc/ThirdParty/icu/53.1.x/solaris10sparc/gcc4_9/release32/lib/libicudata_sb32.so.53
        libicui18n_sb32.so.53 =>         /bamboo/Adhoc/ThirdParty/icu/53.1.x/solaris10sparc/gcc4_9/release32/lib/libicui18n_sb32.so.53
        libicuuc_sb32.so.53 =>   /bamboo/Adhoc/ThirdParty/icu/53.1.x/solaris10sparc/gcc4_9/release32/lib/libicuuc_sb32.so.53
        libpthread.so.1 =>       /lib/libpthread.so.1
        librt.so.1 =>    /lib/librt.so.1
        libnsl.so.1 =>   /lib/libnsl.so.1
        libsocket.so.1 =>        /lib/libsocket.so.1
        libresolv.so.2 =>        /lib/libresolv.so.2
        libxnet.so.1 =>  /lib/libxnet.so.1
        libgssapi_krb5.so.2 =>   /opt/csw/lib/libgssapi_krb5.so.2
        libkrb5.so.3 =>  /opt/csw/lib/libkrb5.so.3
        libkrb5support.so.0 =>   /opt/csw/lib/libkrb5support.so.0
        libk5crypto.so.3 =>      /opt/csw/lib/libk5crypto.so.3
        libcom_err.so.3 =>       /opt/csw/lib/libcom_err.so.3
        libm.so.2 =>     /lib/libm.so.2
        libc.so.1 =>     /lib/libc.so.1
        libgcc_s.so.1 =>         /opt/csw/lib/libgcc_s.so.1
        libaio.so.1 =>   /lib/libaio.so.1
        libmd.so.1 =>    /lib/libmd.so.1
        libmp.so.2 =>    /lib/libmp.so.2
        libscf.so.1 =>   /lib/libscf.so.1
        libintl.so.8 =>  /opt/csw/lib/sparcv8/libintl.so.8
        libdoor.so.1 =>  /lib/libdoor.so.1
        libuutil.so.1 =>         /lib/libuutil.so.1
        libgen.so.1 =>   /lib/libgen.so.1
        libiconv.so.2 =>         /opt/csw/lib/sparcv8/libiconv.so.2
        /lib/libm/libm_hwcap1.so.2
        /platform/sun4v/lib/libc_psr.so.1
        /platform/sun4v/lib/libmd_psr.so.1

LDD output for iodbctest (Not sure how this was built)

        libdl.so.1 =>    /lib/libdl.so.1
        libc.so.1 =>     /lib/libc.so.1
        libm.so.2 =>     /lib/libm.so.2
        /lib/libm/libm_hwcap1.so.2
        /platform/sun4v/lib/libc_psr.so.1

Also, for someone who asked, if I set dbx to break on exceptions, I first break at this stack

(dbx) where -h
current thread: t@1
dbx: forward reference `Connection' not defined, see `help forwardref'
=>[1] __cxa_throw(obj = 0x13a268, tinfo = 0xfef2bf2c, dest = 0xfe204240 = &Simba::Support::ErrorException::~ErrorException()), line 65 in "eh_throw.cc"
  [2] Simba::ODBC::ConnectionAttributes::SetAttribute(this = 0x12d5d0, in_attribute = <value unavailable>, in_value = 0x13a1e8, in_length = -3), line 299 in "ConnectionAttributes.cpp"

and then if I continue, it crashes at the location previously mentioned.

Edit 2: Here's some more stack frames when terminate is called:

(dbx) where -h
current thread: t@1
dbx: forward reference `Connection' not defined, see `help forwardref'
  [1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xffbffeff, 0x0), at 0xff2ce364
  [2] raise(0x6, 0x0, 0x0, 0xff2ad954, 0xffffffff, 0x6), at 0xff267958
  [3] abort(0x132cb0, 0x1, 0xff122f38, 0xedbe0, 0xff333558, 0x0), at 0xff242910
=>[4] __gnu_cxx::__verbose_terminate_handler(), line 95 in "vterminate.cc"
  [5] __cxxabiv1::__terminate(handler = 0xff125098 = &__gnu_cxx::__verbose_terminate_handler()), line 47 in "eh_terminate.cc"
  [6] std::terminate(), line 57 in "eh_terminate.cc"
  [7] __cxa_throw(obj = 0x132cf8, tinfo = 0xfef2bf2c, dest = 0xfe204240 = &Simba::Support::ErrorException::~ErrorException()), line 87 in "eh_throw.cc"
  [8] Simba::ODBC::ConnectionAttributes::SetAttribute(this = 0x12a060, in_attribute = <value unavailable>, in_value = 0x132c78, in_length = -3), line 299 in "ConnectionAttributes.cpp"
  [9] Simba::ODBC::ConnectionState::SQLSetConnectAttr(this = <value unavailable>, in_connection = 0x129e08, Attribute = 1051, ValuePtr = 0x132c78, StringLength = -3), line 495 in "ConnectionState.cpp"
  [10] Simba::ODBC::ConnectionState2::SQLSetConnectAttr(this = 0xd7a30, in_connection = 0x129e08, Attribute = 1051, ValuePtr = 0x132c78, StringLength = -3), line 526 in "ConnectionState2.cpp"
  [11] Simba::ODBC::Connection::SQLSetConnectAttr(this = 0x129e08, Attribute = 1051, ValuePtr = 0x132c78, StringLength = -3), line 1746 in "Connection.cpp"
  [12] Simba::ODBC::SQLSetConnectAttrTask<true>::DoSynchronously(, line 266 in "SQLSetConnectAttrTask.h"
  [13] DoTask<Simba::ODBC::SQLSetConnectAttrTask<true> >(in_functionName = 0xfea68b10 "SQLSetConnectAttr", in_handle = 0x2, in_parameters = STRUCT), line 638 in "CInterface.cpp"
  [14] SQLSetConnectAttrW(ConnectionHandle = 0x2, Attribute = 1051, Value = 0x132c78, StringLength = -3), line 4053 in "CInterface.cpp"
  [15] _iodbcdm_SetConnectOption_init(0x9a568, 0x41b, 0x7b4a0, 0x41, 0x99e68, 0xffffefc8), at 0x23ae0
  [16] _iodbcdm_driverload(0xffbfec10, 0xffbfec40, 0x9a568, 0x1, 0x0, 0x41), at 0x26458
  [17] SQLDriverConnect_Internal(0x9a568, 0x0, 0xffbff590, 0xfffffffd, 0x98dc0, 0x1000), at 0x2a72c
  [18] SQLDriverConnect(0x9a568, 0x0, 0xffbff590, 0xfffffffd, 0x98dc0, 0x1000), at 0x2b7e0
  [19] ODBC_Connect(0xffbffb7b, 0x98c80, 0x0, 0x98c9e, 0xff3303ec, 0x4), at 0x16638
  [20] main(0x2, 0xffbffa7c, 0xffbffa88, 0x99dc0, 0xff3700c0, 0x0), at 0x1837c

Also, I've confirmed that iodbctest was in fact built with gcc

Making all in samples
gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../include -I../include -DNO_FRAMEWORKS   -DWITH_PTHREADS -D_REENTRANT  -m32 -DODBCVER=0x0350 -DIODBC_BUILD=8120326 -MT iodbctest.o -MD -MP -MF .deps/iodbctest.Tpo -c -o iodbctest.o iodbctest.c
mv -f .deps/iodbctest.Tpo .deps/iodbctest.Po
/bin/bash ../libtool --tag=CC    --mode=link gcc -std=gnu99  -m32 -DODBCVER=0x0350 -DIODBC_BUILD=8120326  -static -m32 -o iodbctest iodbctest.o ../iodbc/libiodbc.la 
libtool: link: gcc -std=gnu99 -m32 -DODBCVER=0x0350 -DIODBC_BUILD=8120326 -m32 -o iodbctest iodbctest.o  ../iodbc/.libs/libiodbc.a -ldl

Edit 3: Here's the link command for the .so

/opt/csw/gcc4/bin/g++ -DSIMBA -D_REENTRANT -m32 -fPIC -pthread  -Wall -Wno-unknown-pragmas  -lrt   -O1 -g  -shared API/ImpalaClient_solaris10sparc_gcc4_9_release32.cpp.o API/ImpalaTCLIServiceThreadSafeClient_solaris10sparc_gcc4_9_release32.cpp.o Core/ImpalaConnection_solaris10sparc_gcc4_9_release32.cpp.o Core/ImpalaDriver_solaris10sparc_gcc4_9_release32.cpp.o Core/ImpalaEnvironment_solaris10sparc_gcc4_9_release32.cpp.o Core/ImpalaStatement_solaris10sparc_gcc4_9_release32.cpp.o DataEngine/ImpalaAggregateFunction_solaris10sparc_gcc4_9_release32.cpp.o DataEngine/ImpalaCaseInsensitiveMetadataResult_solaris10sparc_gcc4_9_release32.cpp.o DataEngine/ImpalaDataEngine_solaris10sparc_gcc4_9_release32.cpp.o DataEngine/ImpalaDSIExtQueryExecutor_solaris10sparc_gcc4_9_release32.cpp.o DataEngine/ImpalaFetchThread_solaris10sparc_gcc4_9_release32.cpp.o DataEngine/ImpalaNativeQueryExecutor_solaris10sparc_gcc4_9_release32.cpp.o DataEngine/ImpalaPlaceholderTable_solaris10sparc_gcc4_9_release32.cpp.o DataEngine/ImpalaResultSet_solaris10sparc_gcc4_9_release32.cpp.o DataEngine/ImpalaScalarFunction_solaris10sparc_gcc4_9_release32.cpp.o DataEngine/Metadata/ImpalaColumnsMetadataSource_solaris10sparc_gcc4_9_release32.cpp.o DataEngine/Metadata/ImpalaMetadataHelper_solaris10sparc_gcc4_9_release32.cpp.o DataEngine/Metadata/ImpalaTablesMetadataSource_solaris10sparc_gcc4_9_release32.cpp.o DataEngine/Metadata/ImpalaTypeInfoMetadataSource_solaris10sparc_gcc4_9_release32.cpp.o QueryTranslation/ImpalaSQLGenerator_solaris10sparc_gcc4_9_release32.cpp.o Utilities/ImpalaTypeUtilities_solaris10sparc_gcc4_9_release32.cpp.o Utilities/ImpalaUtilities_solaris10sparc_gcc4_9_release32.cpp.o ../ThirdParty/ImpalaClients_Thrift_0_9_0/TCLIServiceClient/src/TCLIService_solaris10sparc_gcc4_9_release32.cpp.o ../ThirdParty/ImpalaClients_Thrift_0_9_0/TCLIServiceClient/src/TCLIService_constants_solaris10sparc_gcc4_9_release32.cpp.o ../ThirdParty/ImpalaClients_Thrift_0_9_0/TCLIServiceClient/src/TCLIService_types_solaris10sparc_gcc4_9_release32.cpp.o Main_Unix_solaris10sparc_gcc4_9_release32.cpp.o     -mimpure-text -static-libgcc -L./solaris10sparc/gcc4_9/release32 -L/bamboo/bamboo-agent-home/xml-data/build-dir/ThirdParty/icu/53.1.x/solaris10sparc/gcc4_9/release32/lib -licudata_sb32 -licui18n_sb32 -licuuc_sb32 -lpthread -lm -Wl,-M,exports_Solaris.map -lrt -lnsl -lsocket -lresolv -lxnet -Wl,-M,exports_Solaris.map -Wl,-zallextract,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/release32/libSimbaODBC.a,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/release32/libSimbaDSI.a,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/release32/libSimbaSupport.a,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/release32/libAEProcessor.a,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/release32/libCore.a,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/release32/libDSIExt.a,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/release32/libExecutor.a,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/release32/libParser.a,/bamboo/bamboo-agent-home/xml-data/build-dir/Drivers/DriverShared/KerberosSupport/Maintenance/10.1/Lib/solaris10sparc/gcc4_9/release32/libKerberosSupport.a,/bamboo/bamboo-agent-home/xml-data/build-dir/Drivers/DriverShared/ThriftExtension/0.9.0/Maintenance/10.1/Lib/solaris10sparc/gcc4_9/release32/libThriftExtension.a,/bamboo/bamboo-agent-home/xml-data/build-dir/Drivers/DriverShared/DriverSupport/Maintenance/10.1/Lib/solaris10sparc/gcc4_9/release32/libDriverSupport.a -Wl,-zweakextract,/bamboo/bamboo-agent-home/xml-data/build-dir/ThirdParty/openssl/1.1.0/solaris10sparc/gcc4_9/release32/lib/libssl.a,/bamboo/bamboo-agent-home/xml-data/build-dir/ThirdParty/openssl/1.1.0/solaris10sparc/gcc4_9/release32/lib/libcrypto.a,/bamboo/bamboo-agent-home/xml-data/build-dir/Drivers/DriverShared/cyrus-sasl/2.1.26/saslGSSAPI/Maintenance/1.0/Binaries/solaris10sparc/gcc4_9/release32/lib/libsasl2.a,/bamboo/bamboo-agent-home/xml-data/build-dir/ThirdParty/boost/1.57.0_sb_icusb_53.1.x/solaris10sparc/gcc4_9/release32/lib/libboost_sb_date_time.a,/bamboo/bamboo-agent-home/xml-data/build-dir/ThirdParty/boost/1.57.0_sb_icusb_53.1.x/solaris10sparc/gcc4_9/release32/lib/libboost_sb_regex.a,/bamboo/bamboo-agent-home/xml-data/build-dir/ThirdParty/boost/1.57.0_sb_icusb_53.1.x/solaris10sparc/gcc4_9/release32/lib/libboost_sb_thread.a,/bamboo/bamboo-agent-home/xml-data/build-dir/ThirdParty/boost/1.57.0_sb_icusb_53.1.x/solaris10sparc/gcc4_9/release32/lib/libboost_sb_system.a,/bamboo/bamboo-agent-home/xml-data/build-dir/ThirdParty/thrift/0.9.0_openssl1.1.0_boost1.57.0_sb_icusb_53.1.x/solaris10sparc/gcc4_9/release32/lib/libthrift.a,/bamboo/bamboo-agent-home/xml-data/build-dir/ThirdParty/boost/1.57.0_sb_icusb_53.1.x/solaris10sparc/gcc4_9/release32/lib/libboost_sb_atomic.a,/bamboo/bamboo-agent-home/xml-data/build-dir/Drivers/DriverShared/cyrus-sasl/2.1.26/saslGSSAPI/Maintenance/1.0/Binaries/solaris10sparc/gcc4_9/release32/lib/sasl2/libgs2.a -L/bamboo/bamboo-agent-home/xml-data/build-dir/ThirdParty/MIT_Kerberos/1.14/solaris10sparc/gcc4_9/release32/lib -lgssapi_krb5 -lkrb5 -lkrb5support -lk5crypto -lcom_err -o ../Bin/solaris10sparc/gcc4_9/release32/libimpalaodbc_sb32.so

Note how one of the functions in the call-stack is called `__verbose_terminate_handler`. That should have printed something relevant. What did it print? Please show it to us, in full and complete and unmodified. — Some programmer dude, Apr 04 '18 at 19:24
Also, without a [Minimal, Complete, and Verifiable Example](http://stackoverflow.com/help/mcve) it's going to be *very* hard to help you. — Some programmer dude, Apr 04 '18 at 19:25
@Someprogrammerdude I am pretty sure that if OP manages to create MCVE, this will be the answer to the problem. In essence, this question is asking about creating MCVE :) — SergeyA, Apr 04 '18 at 19:26
Lastly, if you actually start the program *inside* the debugger it should catch the exception being thrown (I don't know about the Solaris dbx debugger, but it would be pretty worthless otherwise). So you can see exactly when where and how the exception is being thrown. — Some programmer dude, Apr 04 '18 at 19:27
It prints out `terminate called after throwing an instance of 'Simba::Support::ErrorException' Abort (core dumped)` — Bwmat, Apr 04 '18 at 19:29
How are you compiling your binary? Also, please post the output from `ldd binary`. — Andrew Henle, Apr 04 '18 at 19:41
It shouldn’t matter because of the `catch(...)`, but are the throw and the putative catching defined in different dynamic objects? — Davis Herring, Apr 05 '18 at 01:52
No, the catch is in the same .so, and all frames between them are likewise — Bwmat, Apr 05 '18 at 01:55
What is your *entire* link command? For both the shared object and the actual executable having the problem. I don't see any dependencies on a C++ run-time library in the `ldd` output you posted. I'd think there should be a `libstdc++.so.6` or similar. — Andrew Henle, Apr 05 '18 at 10:47
Interestingly, when I try to build a C++ shared object, **and I link that object with g++**, I always get the dynamic dependencies on both `libgcc_s.so` and `libstdc++.so`, even with the `-static-libgcc` option. With the `-static-libstdc++` option also, I get no dynamic dependencies on either, but I do get a huge shared object. — Andrew Henle, Apr 05 '18 at 18:00

Daniel Jour · Answer 1 · 2018-04-05T14:35:41.973

1

I'm of course a bit guessing in the blue here, and thus this is half-answer half-comment, but exceptions not being caught even if they should sounds a lot like an ABI issue.

Do you compile all libraries and executables working together here with the same compiler? This includes libraries like the C++ standard library!

This answer says that loading a shared library which is built with GCC won't work in an executable built with Solaris Studio, unless you built that executable with Solaris 12.4 or newer and enabled C++11 support via -std=c++11.

Thus an immediate "fix" would be to change / check the compile flags of the executable which loads that shared library with the offending code.

Another difference between the executable and the shared library could be that one is configured for "setjmp/longjmp" exceptions and the other is not. _GLIBCPP_SJLJ_EXCEPTIONS in eh_throw.cc and in some config I found online.

Mention of the different exception handling strategies in GCC docs.

edited Apr 05 '18 at 14:35

answered Apr 05 '18 at 10:58

Daniel Jour

15,896
2
36
63

Iodbctest was *supposed* to have been built with gcc, but I guess that's not the case, given the ldd output? – Bwmat Apr 05 '18 at 14:17
1

It doesn't look like it - I can't see libCrun or libCstd in the ldd output. (These are the libs that the Oracle compiler uses by default). – Paul Floyd Apr 05 '18 at 14:19
@Bwmat *Iodbctest was supposed to have been built with gcc* If it's linking `g++`-built C++ shared objects, it needs to be linked with `g++` (Well, it doesn't **need** to be, but that's certainly the easiest way to get the required C++ dependencies...) – Andrew Henle Apr 05 '18 at 15:25
There's no direct relationship between iodbctest & my binary: the former (indirectly) dynamically loads the latter and uses it via the standard ODBC api. – Bwmat Apr 05 '18 at 15:30
Ideally our shared objects could be loaded by any program(regardless of compiler), could this be accomplished by somehow statically linking to the runtime? – Bwmat Apr 05 '18 at 15:32
@Bwmat You need a GCC version at least 4.9.2 to statically link the C++ run-time library. And doing *that* with a shared object is probably unreliable - what happens if another part of the application causes the C++ run-time shared object to be loaded? That would put *two* copies of the C++ run-time into such a process. – Andrew Henle Apr 05 '18 at 15:39

score 1 · Accepted Answer · answered Apr 09 '18 at 11:31

If you're going to create a C++ shared object that's loaded by a non-C++ executable, you need to ensure your C++ shared object has dynamic dependencies on the proper C++ run-time libraries.

Your C++ shared object that you load with a C executable has no dependency on the libstdc++.so shared object.

This link command for your shared object:

/opt/csw/gcc4/bin/g++ -DSIMBA -D_REENTRANT -m32 -fPIC -pthread
-Wall -Wno-unknown-pragmas  -lrt   -O1 -g  -shared 
API/ImpalaClient_solaris10sparc_gcc4_9_release32.cpp.o 
API/ImpalaTCLIServiceThreadSafeClient_solaris10sparc_gcc4_9_release32.cpp.o
Core/ImpalaConnection_solaris10sparc_gcc4_9_release32.cpp.o 
Core/ImpalaDriver_solaris10sparc_gcc4_9_release32.cpp.o 
Core/ImpalaEnvironment_solaris10sparc_gcc4_9_release32.cpp.o 
Core/ImpalaStatement_solaris10sparc_gcc4_9_release32.cpp.o
DataEngine/ImpalaAggregateFunction_solaris10sparc_gcc4_9_release32.cpp.o
 DataEngine/ImpalaCaseInsensitiveMetadataResult_solaris10sparc_gcc4_9_release32.cpp.o
DataEngine/ImpalaDataEngine_solaris10sparc_gcc4_9_release32.cpp.o
DataEngine/ImpalaDSIExtQueryExecutor_solaris10sparc_gcc4_9_release32.cpp.o
DataEngine/ImpalaFetchThread_solaris10sparc_gcc4_9_release32.cpp.o
DataEngine/ImpalaNativeQueryExecutor_solaris10sparc_gcc4_9_release32.cpp.o
DataEngine/ImpalaPlaceholderTable_solaris10sparc_gcc4_9_release32.cpp.o
DataEngine/ImpalaResultSet_solaris10sparc_gcc4_9_release32.cpp.o
DataEngine/ImpalaScalarFunction_solaris10sparc_gcc4_9_release32.cpp.o
DataEngine/Metadata/ImpalaColumnsMetadataSource_solaris10sparc_gcc4_9_release32.cpp.o
DataEngine/Metadata/ImpalaMetadataHelper_solaris10sparc_gcc4_9_release32.cpp.o
DataEngine/Metadata/ImpalaTablesMetadataSource_solaris10sparc_gcc4_9_release32.cpp.o
DataEngine/Metadata/ImpalaTypeInfoMetadataSource_solaris10sparc_gcc4_9_release32.cpp.o
QueryTranslation/ImpalaSQLGenerator_solaris10sparc_gcc4_9_release32.cpp.o
Utilities/ImpalaTypeUtilities_solaris10sparc_gcc4_9_release32.cpp.o
Utilities/ImpalaUtilities_solaris10sparc_gcc4_9_release32.cpp.o
../ThirdParty/ImpalaClients_Thrift_0_9_0/TCLIServiceClient/src/TCLIService_solaris10sparc_gcc4_9_release32.cpp.o
../ThirdParty/ImpalaClients_Thrift_0_9_0/TCLIServiceClient/src/TCLIService_constants_solaris10sparc_gcc4_9_release32.cpp.o
../ThirdParty/ImpalaClients_Thrift_0_9_0/TCLIServiceClient/src/TCLIService_types_solaris10sparc_gcc4_9_release32.cpp.o
Main_Unix_solaris10sparc_gcc4_9_release32.cpp.o     -mimpure-text -static-libgcc
-L./solaris10sparc/gcc4_9/release32
-L/bamboo/bamboo-agent-home/xml-data/build-dir/ThirdParty/icu/53.1.x/solaris10sparc/gcc4_9/release32/lib
-licudata_sb32 -licui18n_sb32 -licuuc_sb32 -lpthread -lm
-Wl,-M,exports_Solaris.map -lrt -lnsl -lsocket -lresolv -lxnet
-Wl,-M,exports_Solaris.map
-Wl,-zallextract,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/release32/libSimbaODBC.a,
/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/release32/libSimbaDSI.a,
/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/release32/libSimbaSupport.a,
/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/release32/libAEProcessor.a,
/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/release32/libCore.a,
/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/release32/libDSIExt.a,
/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/release32/libExecutor.a,
/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/release32/libParser.a,
/bamboo/bamboo-agent-home/xml-data/build-dir/Drivers/DriverShared/KerberosSupport/Maintenance/10.1/Lib/solaris10sparc/gcc4_9/release32/libKerberosSupport.a,
/bamboo/bamboo-agent-home/xml-data/build-dir/Drivers/DriverShared/ThriftExtension/0.9.0/Maintenance/10.1/Lib/solaris10sparc/gcc4_9/release32/libThriftExtension.a,
/bamboo/bamboo-agent-home/xml-data/build-dir/Drivers/DriverShared/DriverSupport/Maintenance/10.1/Lib/solaris10sparc/gcc4_9/release32/libDriverSupport.a
-Wl,-zweakextract,/bamboo/bamboo-agent-home/xml-data/build-dir/ThirdParty/openssl/1.1.0/solaris10sparc/gcc4_9/release32/lib/libssl.a,
/bamboo/bamboo-agent-home/xml-data/build-dir/ThirdParty/openssl/1.1.0/solaris10sparc/gcc4_9/release32/lib/libcrypto.a,
/bamboo/bamboo-agent-home/xml-data/build-dir/Drivers/DriverShared/cyrus-sasl/2.1.26/saslGSSAPI/Maintenance/1.0/Binaries/solaris10sparc/gcc4_9/release32/lib/libsasl2.a,
/bamboo/bamboo-agent-home/xml-data/build-dir/ThirdParty/boost/1.57.0_sb_icusb_53.1.x/solaris10sparc/gcc4_9/release32/lib/libboost_sb_date_time.a,
/bamboo/bamboo-agent-home/xml-data/build-dir/ThirdParty/boost/1.57.0_sb_icusb_53.1.x/solaris10sparc/gcc4_9/release32/lib/libboost_sb_regex.a,
/bamboo/bamboo-agent-home/xml-data/build-dir/ThirdParty/boost/1.57.0_sb_icusb_53.1.x/solaris10sparc/gcc4_9/release32/lib/libboost_sb_thread.a,
/bamboo/bamboo-agent-home/xml-data/build-dir/ThirdParty/boost/1.57.0_sb_icusb_53.1.x/solaris10sparc/gcc4_9/release32/lib/libboost_sb_system.a,
/bamboo/bamboo-agent-home/xml-data/build-dir/ThirdParty/thrift/0.9.0_openssl1.1.0_boost1.57.0_sb_icusb_53.1.x/solaris10sparc/gcc4_9/release32/lib/libthrift.a,
/bamboo/bamboo-agent-home/xml-data/build-dir/ThirdParty/boost/1.57.0_sb_icusb_53.1.x/solaris10sparc/gcc4_9/release32/lib/libboost_sb_atomic.a,
/bamboo/bamboo-agent-home/xml-data/build-dir/Drivers/DriverShared/cyrus-sasl/2.1.26/saslGSSAPI/Maintenance/1.0/Binaries/solaris10sparc/gcc4_9/release32/lib/sasl2/libgs2.a
-L/bamboo/bamboo-agent-home/xml-data/build-dir/ThirdParty/MIT_Kerberos/1.14/solaris10sparc/gcc4_9/release32/lib
-lgssapi_krb5 -lkrb5 -lkrb5support -lk5crypto -lcom_err
-o ../Bin/solaris10sparc/gcc4_9/release32/libimpalaodbc_sb32.so

produces a C++ shared object without a dynamic dependency on libstdc++.so. Also, note that despite the -static-libgcc argument, there's still a dynamic dependency on libgcc_s.so:

libgcc_s.so.1 =>         /opt/csw/lib/libgcc_s.so.1

That may be because one or all of libicudata_sb32.so,libicui18n_sb32.so, and/or libicuuc_sb32.so were linked in a way the requires a dynamic libgcc. See compile libconfig++ with -static-libgcc and -static-libstdc++ for an example of a question where -static-libgcc and -static-libstdc++ still produced a binary with dynamic dependencies on shared object versions of those libraries.

The C binary that you use to load this shared object is linked with

gcc -std=gnu99 -m32 -DODBCVER=0x0350 -DIODBC_BUILD=8120326 -m32
-o iodbctest iodbctest.o  ../iodbc/.libs/libiodbc.a -ldl

That's not going to result in any dependency on libstdc++.so, nor should it.

And see Linking libstdc++ statically: any gotchas? for just one question about potential issues linking libstdc++ statically. And note that even that question merely deals with statically linking one copy of libstdc++ into an executable. Statically linking libstdc++ into a shared object raises all kinds of other issues: will each C++ shared object liked in get proper access to that one copy of the C++ run-time linked in that way? Or are you going to statically link in multiple copies of libstdc++ into every C++ shared object your process might load? How well with that work? If weird issues start appearing, how would you even begin to debug them?

What happens if a non-C++ executable dynamically loads a C++ shared object with a static copy of libstdc++ inside it, then that same executable dynamically links in another C++ shared object with a dynamic dependency on libstdc++.so? What's going to happen then when a dynamic copy of the C++ runtime from libstdc++.so is loaded after the static copy has already been loaded and initialized? What happens if you reverse the order? What happens if there's an upgrade that changes libstdc++.so, but you don't provide an updated copy of the statically-linked copy of libstdc++?

The bottom line is: if you're creating C++ shared objects that need to be loaded by a non-C++ executable and don't want to deal with all the potential issues listed above, you need to properly record the dynamic dependencies on the C++ run time in all the C++ shared objects.

You need to add something like

-lgcc -lstdc++

to the shared object link commands for your C++ shared objects that can be loaded into a C binary.

The shared object is built from C++ source. It will link without either static or dynamic dependencies on the C++ runtime library? I'd expect it to fail to load at runtime at the least? — Bwmat, Apr 09 '18 at 17:58
@Bwmat Are any of the other shared objects you pull into the executable C++? They could be pulling in the C++ run-time libraries, in which case the `-static-libgcc` might result in multiple copies of that library. What shared objects are linked into your running C process when it fails to catch the exception? You can use `proc -map` in `dbx`, or `pldd PID` from a shell prompt. — Andrew Henle, Apr 10 '18 at 10:37
Adding `-lgcc -lstdc++` to the link seems to solve the problem. Thanks! Before trying that, we noticed that the call to `__cxa_throw` was actually in a different .so than the previous frame! (One of our dependencies, `libicuuc_sb32.so` like you guessed, actually) — Bwmat, Apr 12 '18 at 21:22
Does it even make sense to use `-static-libgcc` but not `-static-libstdc++`? — Bwmat, Apr 12 '18 at 21:24

Debugging 'terminate called after throwing an instance of ...', when the exception _should_ have been caught

2 Answers2