Thrown exception never caught, but thread not killed? - c++
This is happening on a Solaris sparc machine:
-bash-3.2$ uname -a
SunOS b2s-sol10spr-1 5.10 Generic_147147-26 sun4v sparc sun4v
I'm seeing a strange issue with exception handling. Here's a log of a short debugging session:
GNU gdb (GDB) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.10".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./Touchstone_solaris64_iodbc...done.
(gdb) catch throw
Catchpoint 1 (throw)
(gdb) catch catch
Catchpoint 2 (catch)
(gdb) r
Starting program: /bamboo/mattheww/Touchstone_solaris64_iodbc -te Tests/Touchstone/SQL/SqlTestEnv_utf32.xml -ts Tests/Touchstone/SQL/SqlTestSuite.xml -o failure -rtn EXPECTEDFAILURES_QUERIESONLY-15
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]
Simba Test Verbose Log Started on Fri Aug 17 12:51:50 2018
Starting test run
---------------------------
Touchstone test utility for ODBC and OLE DB for OLAP
Version: 4.5.0.5 (64-bit)
Copyright (c) 2018 Simba Technologies Incorporated
__BUILD_INFO__ built at __BUILD_TIME__
getpid=22056
[Switching to Thread 1 (LWP 1)]
Catchpoint 1 (exception thrown), __cxxabiv1::__cxa_throw (obj=0x101ec52f0, tinfo=0xffffffff7b8d0138 <typeinfo for Simba::SQLEngine::SESqlErrorException>, dest=
0xffffffff7a697850 <Simba::SQLEngine::SESqlErrorException::~SESqlErrorException()>) at /home/dam/mgar/pkg/gcc5/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-5.5.0/libstdc++-v3/libsupc++/eh_throw.cc:65
65 /home/dam/mgar/pkg/gcc5/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-5.5.0/libstdc++-v3/libsupc++/eh_throw.cc: No such file or directory.
(gdb) where
#0 __cxxabiv1::__cxa_throw (obj=0x101ec52f0, tinfo=0xffffffff7b8d0138 <typeinfo for Simba::SQLEngine::SESqlErrorException>, dest=0xffffffff7a697850 <Simba::SQLEngine::SESqlErrorException::~SESqlErrorException()>)
at /home/dam/mgar/pkg/gcc5/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-5.5.0/libstdc++-v3/libsupc++/eh_throw.cc:65
#1 0xffffffff7a6f4188 in Simba::SQLEngine::AEScalarFnMetadataFactory::ValidateCotArgs (in_argument=0) at AEBuilder/Value/AEScalarFnMetadataFactory.cpp:2186
#2 0xffffffff7ab72d28 in Simba::SQLEngine::ETCotFn::RetrieveData (this=0x101db8ff0, io_dataRequest=...) at ETree/Value/ScalarFunctions/ETCotFn.cpp:37
#3 0xffffffff7a98c96c in Simba::SQLEngine::ETComparisonT<Simba::SQLEngine::ETEQFunctorT<double> >::GetLeftData (this=0x101db90f0) at Include/ETree/ETComparisonT.h:80
#4 0xffffffff7a976ac4 in Simba::SQLEngine::ETComparisonT<Simba::SQLEngine::ETEQFunctorT<double> >::Evaluate (this=0x101db90f0) at Include/ETree/ETComparisonT.h:104
#5 0xffffffff7a9c2510 in Simba::SQLEngine::ETSelect::DoMove (this=0x101ec53f0, in_moveRequest=...) at ETree/Relational/ETSelect.cpp:143
#6 0xffffffff7a8b4e18 in Simba::SQLEngine::ETRelationalExpr::Move (this=0x101ec53f0, in_moveRequest=...) at ../../../Include/SQLEngine/Executor/ETree/ETRelationalExpr.h:352
#7 0xffffffff7a9b8c90 in Simba::SQLEngine::ETProject::DoMove (this=0x101ec5450, in_moveRequest=...) at ETree/Relational/ETProject.cpp:143
#8 0xffffffff7a8b4e18 in Simba::SQLEngine::ETRelationalExpr::Move (this=0x101ec5450, in_moveRequest=...) at ../../../Include/SQLEngine/Executor/ETree/ETRelationalExpr.h:352
#9 0xffffffff7a8b4ae8 in Simba::SQLEngine::ETResultSet::Move (this=0x101dd6c40, in_direction=Simba::DSI::DSI_DIR_NEXT, in_offset=0) at ETResultSet.cpp:158
#10 0xffffffff7ad4f590 in Simba::ODBC::ForwardOnlyCursor::FetchRowset (this=0x101ec5650, in_orientation=1, in_offset=0, in_rowsetSize=1, in_ard=0x1014de6f0, in_rowStatusPtr=0x0, in_rowsProcessedPtr=0x0)
at Cursor/ForwardOnlyCursor.cpp:329
#11 0xffffffff7adc0c88 in Simba::ODBC::QueryManager::FetchRowset (this=0x101eb4810, in_orientation=1, in_offset=0, in_rowsetSize=1, in_rowStatusPtr=0x0, in_rowsProcessedPtr=0x0) at QueryManager/QueryManager.cpp:87
#12 0xffffffff7adf93a0 in Simba::ODBC::StatementStateCursor::DoFetchScroll (this=0x101b12280, in_fetchOrientation=1, in_fetchOffset=0) at Statement/StatementStateCursor.cpp:823
#13 0xffffffff7ae06f18 in Simba::ODBC::StatementState5::SQLFetch (this=0x101b12280) at Statement/StatementState5.cpp:74
#14 0xffffffff7add6f20 in Simba::ODBC::Statement::SQLFetch (this=0x101e63c30) at Statement/Statement.cpp:986
#15 0xffffffff7acb1610 in Simba::ODBC::SQLFetchTask::DoSynchronously (in_stmt=..., in_params=...) at CInterface/SQLFetchTask.h:73
#16 0xffffffff7acc5884 in DoTask<Simba::ODBC::SQLFetchTask> (in_functionName=0xffffffff7af8fcb0 "SQLFetch", in_handle=0x3, in_parameters=...) at CInterface/CInterface.cpp:679
#17 0xffffffff7ac9ab3c in SQLFetch (StatementHandle=0x3) at CInterface/CInterface.cpp:1693
#18 0xffffffff7d32a1f4 in SQLFetch_Internal (hstmt=0x101b04fb0) at fetch.c:161
#19 0xffffffff7d32a560 in SQLFetch (hstmt=0x101b04fb0) at fetch.c:230
#20 0x00000001001f7454 in Simba::ODBCTest::Cli::SqlFetch (this=0x10143a3b0 <Simba::ODBCTest::Singleton<Simba::ODBCTest::Cli>::m_instance>, handle=0x101b04fb0) at SimbaODBCTestFramework/Cli/Cli.cpp:1109
#21 0x00000001002c9c98 in Simba::ODBCTest::Statement::SqlFetch (this=0x101e640a0, outcome=..., callerFile=0x100df8af0 "TestCases/SQLTests/ODBCXmlResultTestsBase.cpp", callerLine=828) at SimbaODBCTestFramework/ODBC/Statement.cpp:200
#22 0x0000000100c9ae98 in Simba::ODBCTest::ODBCXmlResultTestsBase::Pimpl::ValidateRows (this=0x1014e0640, test=..., xmlResult=0x1014df050) at TestCases/SQLTests/ODBCXmlResultTestsBase.cpp:828
#23 0x0000000100c96a94 in Simba::ODBCTest::ODBCXmlResultTestsBase::DoResultValidation (this=0x1018fc800, test=..., xmlFileName=..., expectedFileName=..., queryFileName=...) at TestCases/SQLTests/ODBCXmlResultTestsBase.cpp:504
#24 0x0000000100ca5ca4 in Simba::ODBCTest::ODBCXmlSimpleResultTestsBase::executeTest (this=0x1018fc800) at TestCases/SQLTests/ODBCXmlSimpleResultTestsBase.cpp:215
#25 0x0000000100ca8478 in Simba::Test::Case::runTest (this=0x1018fc800, runId=...) at TestFrameworkLibrary/SBTCase.cpp:180
#26 0x0000000100cb3b58 in Simba::Test::Engine::runTest (this=0xffffffff7ffff2a0, test=0x1018fc800) at TestFrameworkLibrary/SBTEngine.cpp:219
#27 0x0000000100cb3368 in Simba::Test::Engine::RunTests (this=0xffffffff7ffff2a0, testEnv=0x1014dfed0, loopCount=1) at TestFrameworkLibrary/SBTEngine.cpp:186
#28 0x00000001001f2090 in (anonymous namespace)::DoMain (argc=9, argv=0xffffffff7ffff898) at Main.cpp:557
#29 0x00000001001f256c in main (argc=9, argv=0xffffffff7ffff898) at Main.cpp:581
(gdb) cont
Continuing.
Catchpoint 1 (exception thrown), __cxxabiv1::__cxa_throw (obj=0x101ff73b0, tinfo=0x1013b9960 <typeinfo for Simba::Test::ValueMismatchException>, dest=0x100ce4e34 <Simba::Test::ValueMismatchException::~ValueMismatchException()>)
at /home/dam/mgar/pkg/gcc5/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-5.5.0/libstdc++-v3/libsupc++/eh_throw.cc:65
65 in /home/dam/mgar/pkg/gcc5/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-5.5.0/libstdc++-v3/libsupc++/eh_throw.cc
(gdb) where
#0 __cxxabiv1::__cxa_throw (obj=0x101ff73b0, tinfo=0x1013b9960 <typeinfo for Simba::Test::ValueMismatchException>, dest=0x100ce4e34 <Simba::Test::ValueMismatchException::~ValueMismatchException()>)
at /home/dam/mgar/pkg/gcc5/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-5.5.0/libstdc++-v3/libsupc++/eh_throw.cc:65
#1 0x0000000100ce4f28 in Simba::Test::ValueMismatchException::raise (this=0xffffffff7fffdd38) at TestFrameworkLibrary/Exceptions/SBTValueMismatchException.cpp:28
#2 0x000000010029e524 in Simba::ODBCTest::RaiseMismatchException (msg=...) at SimbaODBCTestFramework/Framework/VerifyValues.h:29
#3 0x000000010033c3d4 in Simba::ODBCTest::VerifyAndThrowComparator<Simba::ODBCTest::Comparator<short> > (comparator=..., msg=..., callerFile=0x100df8af0 "TestCases/SQLTests/ODBCXmlResultTestsBase.cpp", callerLine=888)
at SimbaODBCTestFramework/Framework/VerifyValues.h:227
#4 0x000000010033c1b0 in Simba::ODBCTest::VerifyAndThrow<short> (expected=#0xffffffff7fffe34e: 1, actual=#0xffffffff7fffe396: 100, msg=..., callerFile=0x100df8af0 "TestCases/SQLTests/ODBCXmlResultTestsBase.cpp", callerLine=888)
at SimbaODBCTestFramework/Framework/VerifyValues.h:251
#5 0x0000000100c9b450 in Simba::ODBCTest::ODBCXmlResultTestsBase::Pimpl::ValidateRows (this=0x1014e0640, test=..., xmlResult=0x1014df050) at TestCases/SQLTests/ODBCXmlResultTestsBase.cpp:888
#6 0x0000000100c96a94 in Simba::ODBCTest::ODBCXmlResultTestsBase::DoResultValidation (this=0x1018fc800, test=..., xmlFileName=..., expectedFileName=..., queryFileName=...) at TestCases/SQLTests/ODBCXmlResultTestsBase.cpp:504
#7 0x0000000100ca5ca4 in Simba::ODBCTest::ODBCXmlSimpleResultTestsBase::executeTest (this=0x1018fc800) at TestCases/SQLTests/ODBCXmlSimpleResultTestsBase.cpp:215
#8 0x0000000100ca8478 in Simba::Test::Case::runTest (this=0x1018fc800, runId=...) at TestFrameworkLibrary/SBTCase.cpp:180
#9 0x0000000100cb3b58 in Simba::Test::Engine::runTest (this=0xffffffff7ffff2a0, test=0x1018fc800) at TestFrameworkLibrary/SBTEngine.cpp:219
#10 0x0000000100cb3368 in Simba::Test::Engine::RunTests (this=0xffffffff7ffff2a0, testEnv=0x1014dfed0, loopCount=1) at TestFrameworkLibrary/SBTEngine.cpp:186
#11 0x00000001001f2090 in (anonymous namespace)::DoMain (argc=9, argv=0xffffffff7ffff898) at Main.cpp:557
#12 0x00000001001f256c in main (argc=9, argv=0xffffffff7ffff898) at Main.cpp:581
(gdb) cont
Continuing.
Catchpoint 2 (exception caught), __cxxabiv1::__cxa_begin_catch (exc_obj_in=0x101ff7390) at /home/dam/mgar/pkg/gcc5/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-5.5.0/libstdc++-v3/libsupc++/eh_catch.cc:41
41 /home/dam/mgar/pkg/gcc5/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-5.5.0/libstdc++-v3/libsupc++/eh_catch.cc: No such file or directory.
(gdb) where
#0 __cxxabiv1::__cxa_begin_catch (exc_obj_in=0x101ff7390) at /home/dam/mgar/pkg/gcc5/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-5.5.0/libstdc++-v3/libsupc++/eh_catch.cc:41
#1 0x0000000100ca8774 in Simba::Test::Case::runTest (this=0x1018fc800, runId=...) at TestFrameworkLibrary/SBTCase.cpp:183
#2 0x0000000100cb3b58 in Simba::Test::Engine::runTest (this=0xffffffff7ffff2a0, test=0x1018fc800) at TestFrameworkLibrary/SBTEngine.cpp:219
#3 0x0000000100cb3368 in Simba::Test::Engine::RunTests (this=0xffffffff7ffff2a0, testEnv=0x1014dfed0, loopCount=1) at TestFrameworkLibrary/SBTEngine.cpp:186
#4 0x00000001001f2090 in (anonymous namespace)::DoMain (argc=9, argv=0xffffffff7ffff898) at Main.cpp:557
#5 0x00000001001f256c in main (argc=9, argv=0xffffffff7ffff898) at Main.cpp:581
(gdb) info share
From To Syms Read Shared Object Library
0xffffffff7f606ca0 0xffffffff7f634270 Yes (*) /usr/lib/sparcv9/ld.so.1
Yes (*) /bamboo/mattheww/icu-53.1.x/release64/lib//libicudata_sb64.so.53
0xffffffff7d8e00e8 0xffffffff7da07e0c Yes (*) /bamboo/mattheww/icu-53.1.x/release64/lib//libicui18n_sb64.so.53
0xffffffff7d56a798 0xffffffff7d62c31c Yes (*) /bamboo/mattheww/icu-53.1.x/release64/lib//libicuuc_sb64.so.53
Yes (*) /lib/64/libpthread.so.1
0xffffffff7d30f8b0 0xffffffff7d377994 Yes /usr/local/odbc/dm/iodbc-3.52.8_gcc/64/debug/lib//libiodbc.so.2
0xffffffff7d104fe0 0xffffffff7d10cc20 Yes (*) /lib/64/libsocket.so.1
0xffffffff7cf22340 0xffffffff7cf9e350 Yes (*) /lib/64/libnsl.so.1
0xffffffff7cca9d38 0xffffffff7cd4a6a8 Yes /opt/csw/lib/64/libstdc++.so.6
0xffffffff7ca0b080 0xffffffff7ca7b7a8 Yes (*) /lib/64/libm.so.2
0xffffffff7c802d68 0xffffffff7c806000 Yes (*) /lib/64/librt.so.1
0xffffffff7c602ef8 0xffffffff7c610028 Yes /opt/csw/lib/64/libgcc_s.so.1
0xffffffff7c32ed60 0xffffffff7c3dd4b0 Yes (*) /lib/64/libc.so.1
Yes (*) /lib/64/libdl.so.1
0xffffffff7bf02328 0xffffffff7bf09b38 Yes /usr/sfw/lib/64/libgcc_s.so.1
0xffffffff7bd01e60 0xffffffff7bd076ac Yes (*) /lib/64/libaio.so.1
0xffffffff7bb008a0 0xffffffff7bb0c880 Yes (*) /lib/64/libmd.so.1
0xffffffff7c000460 0xffffffff7c00137c Yes (*) /platform/sun4v/lib/sparcv9/libc_psr.so.1
0xffffffff79dece38 0xffffffff7ae0d3ec Yes /bamboo/mattheww/DRIVER
0xffffffff796009b8 0xffffffff7960c840 Yes (*) /platform/sun4v/lib/sparcv9/libmd_psr.so.1
0xffffffff79400bb0 0xffffffff79402bb0 Yes (*) /lib/64/libmp.so.2
0xffffffff79207690 0xffffffff79217630 Yes (*) /lib/64/libscf.so.1
0xffffffff79001358 0xffffffff79002008 Yes (*) /lib/64/libdoor.so.1
0xffffffff78e02518 0xffffffff78e06c58 Yes (*) /lib/64/libuutil.so.1
0xffffffff78c01f08 0xffffffff78c06104 Yes (*) /lib/64/libgen.so.1
0xffffffff78a03030 0xffffffff78a21078 Yes /usr/local/odbc/dm/iodbc-3.52.8_gcc/64/debug/lib//libiodbcinst.so
(*): Shared library is missing debugging information.
(gdb) quit
After the first exception is thrown, frame 14 has a catch block for a base class of SESqlErrorException, so it should be caught there (and there are no intervening catch blocks that should). Yet, gdb's catch catch fails to break.
Also, the thread/process isn't killed; instead it seems like execution continues somehow (without causing any other problems) until we return into the main binary (frame 20 after the initial throw). I'm still not sure exactly where execution continues after the throw, will need to look into that later.
But, it seems that exception handling is working in the main binary, as we break when the main binary throws & catches an exception.
I don't have it in the log above, but I've noticed that the address of the instruction it breaks on when throwing the exception (i.e __cxxabiv1::__cxa_begin_catch) is actually slightly outside of the memory range that info share shows for libstdc++.so.6. How do I interpret that? I was looking at that, because earlier I had noticed that we had incorrectly built libicui18n_sb64.so.53 to be statically-linked with the C++ runtime, and when this issue occurred, the instruction doing the throw was (as far as I could tell, again it was a little outside of the info share range, but not in any other library's range) in libicui18n_sb64.so.53. I thought this was the source of the issue (throwing an exception using code from one copy of the runtime, so it wouldn't be caught by another copy), but fixing that library didn't make the issue go away.
Something else I noticed was that it claims that __cxxabiv1::__cxa_throw comes from /home/dam/mgar/pkg/gcc5/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-5.5.0/libstdc++-v3/libsupc++/eh_throw.cc:65, which makes me a bit suspicious since we compiled everything with gcc 4.9, but not sure if that's an issue.
Here's some information about the dependencies of all the libraries/binaries in the callstack:
Dependencies for /bamboo/mattheww/icu-53.1.x/release64/lib//libicui18n_sb64.so.53:
libicuuc_sb64.so.53 => /bamboo/mattheww/icu-53.1.x/release64/lib//libicuuc_sb64.so.53
libicudata_sb64.so.53 => /bamboo/mattheww/icu-53.1.x/release64/lib//libicudata_sb64.so.53
libpthread.so.1 => /lib/64/libpthread.so.1
libstdc++.so.6 => /opt/csw/lib/64/libstdc++.so.6
libm.so.2 => /lib/64/libm.so.2
librt.so.1 => /lib/64/librt.so.1
libgcc_s.so.1 => /opt/csw/lib/64/libgcc_s.so.1
libc.so.1 => /lib/64/libc.so.1
libaio.so.1 => /lib/64/libaio.so.1
libmd.so.1 => /lib/64/libmd.so.1
/lib/sparcv9/../libm/sparcv9/libm_hwcap1.so.2
/platform/sun4v/lib/sparcv9/libc_psr.so.1
/platform/sun4v/lib/sparcv9/libmd_psr.so.1
Dependencies for /bamboo/mattheww/icu-53.1.x/release64/lib//libicuuc_sb64.so.53:
libicudata_sb64.so.53 => /bamboo/mattheww/icu-53.1.x/release64/lib//libicudata_sb64.so.53
libpthread.so.1 => /lib/64/libpthread.so.1
libstdc++.so.6 => /opt/csw/lib/64/libstdc++.so.6
libm.so.2 => /lib/64/libm.so.2
librt.so.1 => /lib/64/librt.so.1
libgcc_s.so.1 => /opt/csw/lib/64/libgcc_s.so.1
libc.so.1 => /lib/64/libc.so.1
libaio.so.1 => /lib/64/libaio.so.1
libmd.so.1 => /lib/64/libmd.so.1
/lib/sparcv9/../libm/sparcv9/libm_hwcap1.so.2
/platform/sun4v/lib/sparcv9/libc_psr.so.1
/platform/sun4v/lib/sparcv9/libmd_psr.so.1
Dependencies for /usr/local/odbc/dm/iodbc-3.52.8_gcc/64/debug/lib//libiodbc.so.2:
libdl.so.1 => /lib/64/libdl.so.1
libc.so.1 => /lib/64/libc.so.1
libgcc_s.so.1 => /usr/sfw/lib/64/libgcc_s.so.1
libm.so.2 => /lib/64/libm.so.2
/lib/sparcv9/../libm/sparcv9/libm_hwcap1.so.2
/platform/sun4v/lib/sparcv9/libc_psr.so.1
Dependencies for /bamboo/mattheww/DRIVER:
libstdc++.so.6 => /opt/csw/lib/64/libstdc++.so.6
libicudata_sb64.so.53 => /bamboo/mattheww/icu-53.1.x/release64/lib//libicudata_sb64.so.53
libicui18n_sb64.so.53 => /bamboo/mattheww/icu-53.1.x/release64/lib//libicui18n_sb64.so.53
libicuuc_sb64.so.53 => /bamboo/mattheww/icu-53.1.x/release64/lib//libicuuc_sb64.so.53
libpthread.so.1 => /lib/64/libpthread.so.1
libsocket.so.1 => /lib/64/libsocket.so.1
libnsl.so.1 => /lib/64/libnsl.so.1
libm.so.2 => /lib/64/libm.so.2
librt.so.1 => /lib/64/librt.so.1
libgcc_s.so.1 => /opt/csw/lib/64/libgcc_s.so.1
libc.so.1 => /lib/64/libc.so.1
libmp.so.2 => /lib/64/libmp.so.2
libmd.so.1 => /lib/64/libmd.so.1
libscf.so.1 => /lib/64/libscf.so.1
libaio.so.1 => /lib/64/libaio.so.1
libdoor.so.1 => /lib/64/libdoor.so.1
libuutil.so.1 => /lib/64/libuutil.so.1
libgen.so.1 => /lib/64/libgen.so.1
/lib/sparcv9/../libm/sparcv9/libm_hwcap1.so.2
/platform/sun4v/lib/sparcv9/libc_psr.so.1
/platform/sun4v/lib/sparcv9/libmd_psr.so.1
Dependencies for ./Touchstone_solaris64_iodbc:
libicudata_sb64.so.53 => /bamboo/mattheww/icu-53.1.x/release64/lib//libicudata_sb64.so.53
libicui18n_sb64.so.53 => /bamboo/mattheww/icu-53.1.x/release64/lib//libicui18n_sb64.so.53
libicuuc_sb64.so.53 => /bamboo/mattheww/icu-53.1.x/release64/lib//libicuuc_sb64.so.53
libpthread.so.1 => /lib/64/libpthread.so.1
libiodbc.so.2 => /usr/local/odbc/dm/iodbc-3.52.8_gcc/64/debug/lib//libiodbc.so.2
libsocket.so.1 => /lib/64/libsocket.so.1
libnsl.so.1 => /lib/64/libnsl.so.1
libstdc++.so.6 => /opt/csw/lib/64/libstdc++.so.6
libm.so.2 => /lib/64/libm.so.2
librt.so.1 => /lib/64/librt.so.1
libgcc_s.so.1 => /opt/csw/lib/64/libgcc_s.so.1
libc.so.1 => /lib/64/libc.so.1
libdl.so.1 => /lib/64/libdl.so.1
libgcc_s.so.1 => /usr/sfw/lib/64/libgcc_s.so.1
libmp.so.2 => /lib/64/libmp.so.2
libmd.so.1 => /lib/64/libmd.so.1
libscf.so.1 => /lib/64/libscf.so.1
libaio.so.1 => /lib/64/libaio.so.1
libdoor.so.1 => /lib/64/libdoor.so.1
libuutil.so.1 => /lib/64/libuutil.so.1
libgen.so.1 => /lib/64/libgen.so.1
/lib/sparcv9/../libm/sparcv9/libm_hwcap1.so.2
/platform/sun4v/lib/sparcv9/libc_psr.so.1
/platform/sun4v/lib/sparcv9/libmd_psr.so.1
They all depend on /opt/csw/lib/64/libstdc++.so.6 & /opt/csw/lib/64/libgcc_s.so.1, I'm not sure if any other libraries would be relevant w.r.t. exception handling? (I've read about/seen issues when mixing gcc & 'native' runtimes, but I don't think that's happening here?)
Here's how the library (/bamboo/mattheww/DRIVER) was built:
Example command for compiling one of the .cpp files (I removed a bunch of include directories)
/opt/csw/gcc4/bin/g++ -DSIZEOF_LONG_INT=8 -DSQL_WCHART_CONVERT -DHAVE_MEMMOVE -m64 -fPIC -pthread -Wall -Wno-unknown-pragmas -DSIMBA -D_REENTRANT -DCLUNIX -DNDEBUG -D_POSIX_PTHREAD_SEMANTICS -O0 -g -D_DEBUG -c Common/QSTableMetadataFile.cpp -o Common/QSTableMetadataFile_solaris10sparc_gcc4_9_debug64.cpp.o
Command used to link (removed a bunch of .o files)
/opt/csw/gcc4/bin/g++ -DSIMBA -D_REENTRANT -m64 -fPIC -pthread -Wall -Wno-unknown-pragmas -lrt -O0 -g -shared -L/bamboo/bamboo-agent-home/xml-data/build-dir/ThirdParty/icu/53.1.x/solaris10sparc/gcc4_9/release64/lib -lstdc++ -licudata_sb64 -licui18n_sb64 -licuuc_sb64 -lpthread -lm -lsocket -lnsl -Wl,-M,exports_SunOS.map -Wl,-zallextract,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/debug64/libSimbaDSI.a,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/debug64/libSimbaSupport.a,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/debug64/libAEProcessor.a,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/debug64/libCore.a,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/debug64/libDSIExt.a,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/debug64/libExecutor.a,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/debug64/libParser.a,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/debug64/libSimbaODBC.a -Wl,-zweakextract -o ../Bin/solaris10sparc/gcc4_9/debug64/libQuickstart64.so
Another thing to mention is that this happens in 64-bit, but not 32-bit. Originally, the 32-bit version of libicui18n_sb64.so.53 had been dynamically-linked to the runtime, while libicui18n_sb64.so.53 hadn't, so I thought that difference was the cause, but it didn't change the observed behaviour.
edit:
(gdb) where
#0 __cxxabiv1::__cxa_throw (obj=0x101ec52f0, tinfo=0xffffffff7b8d0138 <typeinfo for Simba::SQLEngine::SESqlErrorException>, dest=0xffffffff7a697850 <Simba::SQLEngine::SESqlErrorException::~SESqlErrorException()>)
at /home/dam/mgar/pkg/gcc5/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-5.5.0/libstdc++-v3/libsupc++/eh_throw.cc:65
#1 0xffffffff7a6f4188 in Simba::SQLEngine::AEScalarFnMetadataFactory::ValidateCotArgs (in_argument=0) at AEBuilder/Value/AEScalarFnMetadataFactory.cpp:2186
#2 0xffffffff7ab72d28 in Simba::SQLEngine::ETCotFn::RetrieveData (this=0x101db8ff0, io_dataRequest=...) at ETree/Value/ScalarFunctions/ETCotFn.cpp:37
#3 0xffffffff7a98c96c in Simba::SQLEngine::ETComparisonT<Simba::SQLEngine::ETEQFunctorT<double> >::GetLeftData (this=0x101db90f0) at Include/ETree/ETComparisonT.h:80
#4 0xffffffff7a976ac4 in Simba::SQLEngine::ETComparisonT<Simba::SQLEngine::ETEQFunctorT<double> >::Evaluate (this=0x101db90f0) at Include/ETree/ETComparisonT.h:104
#5 0xffffffff7a9c2510 in Simba::SQLEngine::ETSelect::DoMove (this=0x101ec53f0, in_moveRequest=...) at ETree/Relational/ETSelect.cpp:143
#6 0xffffffff7a8b4e18 in Simba::SQLEngine::ETRelationalExpr::Move (this=0x101ec53f0, in_moveRequest=...) at ../../../Include/SQLEngine/Executor/ETree/ETRelationalExpr.h:352
#7 0xffffffff7a9b8c90 in Simba::SQLEngine::ETProject::DoMove (this=0x101ec5450, in_moveRequest=...) at ETree/Relational/ETProject.cpp:143
#8 0xffffffff7a8b4e18 in Simba::SQLEngine::ETRelationalExpr::Move (this=0x101ec5450, in_moveRequest=...) at ../../../Include/SQLEngine/Executor/ETree/ETRelationalExpr.h:352
#9 0xffffffff7a8b4ae8 in Simba::SQLEngine::ETResultSet::Move (this=0x101dd6c40, in_direction=Simba::DSI::DSI_DIR_NEXT, in_offset=0) at ETResultSet.cpp:158
<Snipped as this post is now too long>
(gdb) fin
Run till exit from #0 __cxxabiv1::__cxa_throw (obj=0x101ec52f0, tinfo=0xffffffff7b8d0138 <typeinfo for Simba::SQLEngine::SESqlErrorException>, dest=0xffffffff7a697850 <Simba::SQLEngine::SESqlErrorException::~SESqlErrorException()>)
at /home/dam/mgar/pkg/gcc5/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-5.5.0/libstdc++-v3/libsupc++/eh_throw.cc:65
0xffffffff7a8b4e38 in Simba::SQLEngine::ETRelationalExpr::Move (this=0x101ec5450, in_moveRequest=...) at ../../../Include/SQLEngine/Executor/ETree/ETRelationalExpr.h:357
357 ../../../Include/SQLEngine/Executor/ETree/ETRelationalExpr.h: No such file or directory.
(gdb) where
#0 0xffffffff7a8b4e38 in Simba::SQLEngine::ETRelationalExpr::Move (this=0x101ec5450, in_moveRequest=...) at ../../../Include/SQLEngine/Executor/ETree/ETRelationalExpr.h:357
#1 0xffffffff7a8b4ae8 in Simba::SQLEngine::ETResultSet::Move (this=0x101dd6c40, in_direction=Simba::DSI::DSI_DIR_NEXT, in_offset=0) at ETResultSet.cpp:158
<Snipped as this post is now too long>
(gdb)
I'm not sure what exactly it means to do a fin in GDB when the exception handling machinery is about to unwind the stack, but it's back in the non-exceptional flow of code, without the exception being caught...
Edit:
I've uploaded a zip file containing two binaries, one that works and one that doesn't (when I rebuild myself, it works, when our automated build system does, it doesn't): https://simba.app.box.com/s/qzo8735h9nzyv6t4x2lhzze896v361t1
You can reproduce the issue with iodbctest using a connection string like
DRIVER=<path to driver>;DBF=<path to DBF directory>
and executing the query
select dbl_zero from trig where COT(dbl_zero) = dbl_zero
Also, I dissassembled both the function throwing the exception, and the function which should catch that exception, in both binaries, and they were they same (other than some constants which I assume corresponded to different addresses).
Edit:
I've created logs of when the test is run, with both working & broken binaries, using LD_DEBUG=bindings: https://simba.box.com/s/w5y246hb4ydm97krjeyjykc90zvjqfo3
I've noticed a few differences, but not sure exactly how to interpret them
Related
ownCloud 10.0.7 failed to connect to the database
Date: April 2018 - Google Cloud Platform - Deploy a predesigned solution (Marketplace) - ownCloud Certified by Bitnami
Running correct (It was not modified, since the initial installation)
Date: May 08, 2019:
Exception occurred while logging exception: Failed to connect to the database: An exception occured in driver: SQLSTATE[HY000] [2002] Connection refused
#0 /opt/bitnami/apps/owncloud/htdocs/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(429): OC\DB\Connection->connect()
#1 /opt/bitnami/apps/owncloud/htdocs/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(389): Doctrine\DBAL\Connection->getDatabasePlatformVersion()
#2 /opt/bitnami/apps/owncloud/htdocs/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(328): Doctrine\DBAL\Connection->detectDatabasePlatform()
#3 /opt/bitnami/apps/owncloud/htdocs/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(623): Doctrine\DBAL\Connection->getDatabasePlatform()
#4 /opt/bitnami/apps/owncloud/htdocs/lib/private/DB/Connection.php(145): Doctrine\DBAL\Connection->setTransactionIsolation(2)
#5 /opt/bitnami/apps/owncloud/htdocs/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/DriverManager.php(172): OC\DB\Connection->__construct(Array, Object(Doctrine\DBAL\Driver\PDOMySql\Driver), Object(Doctrine\DBAL\Configuration), Object(Doctrine\Common\EventManager))
#6 /opt/bitnami/apps/owncloud/htdocs/lib/private/DB/ConnectionFactory.php(145): Doctrine\DBAL\DriverManager::getConnection(Array, Object(Doctrine\DBAL\Configuration), Object(Doctrine\Common\EventManager))
#7 /opt/bitnami/apps/owncloud/htdocs/lib/private/Server.php(493): OC\DB\ConnectionFactory->getConnection(‘mysql’, Array)
#8 /opt/bitnami/apps/owncloud/htdocs/lib/composer/pimple/pimple/src/Pimple/Container.php(113): OC\Server->OC{closure}(Object(OC\Server))
#9 /opt/bitnami/apps/owncloud/htdocs/lib/private/AppFramework/Utility/SimpleContainer.php(111): Pimple\Container->offsetGet(‘DatabaseConnect…’)
#10 /opt/bitnami/apps/owncloud/htdocs/lib/private/ServerContainer.php(87): OC\AppFramework\Utility\SimpleContainer->query(‘DatabaseConnect…’)
#11 /opt/bitnami/apps/owncloud/htdocs/lib/private/Server.php(1160): OC\ServerContainer->query(‘DatabaseConnect…’)
#12 /opt/bitnami/apps/owncloud/htdocs/lib/private/Server.php(370): OC\Server->getDatabaseConnection()
#13 /opt/bitnami/apps/owncloud/htdocs/lib/composer/pimple/pimple/src/Pimple/Container.php(113): OC\Server->OC{closure}(Object(OC\Server))
#14 /opt/bitnami/apps/owncloud/htdocs/lib/private/AppFramework/Utility/SimpleContainer.php(111): Pimple\Container->offsetGet(‘AppConfig’)
#15 /opt/bitnami/apps/owncloud/htdocs/lib/private/ServerContainer.php(87): OC\AppFramework\Utility\SimpleContainer->query(‘AppConfig’)
#16 /opt/bitnami/apps/owncloud/htdocs/lib/private/Server.php(1089): OC\ServerContainer->query(‘AppConfig’)
#17 /opt/bitnami/apps/owncloud/htdocs/lib/private/Server.php(547): OC\Server->getAppConfig()
#18 /opt/bitnami/apps/owncloud/htdocs/lib/composer/pimple/pimple/src/Pimple/Container.php(113): OC\Server->OC{closure}(Object(OC\Server))
#19 /opt/bitnami/apps/owncloud/htdocs/lib/private/AppFramework/Utility/SimpleContainer.php(111): Pimple\Container->offsetGet(‘AppManager’)
#20 /opt/bitnami/apps/owncloud/htdocs/lib/private/ServerContainer.php(87): OC\AppFramework\Utility\SimpleContainer->query(‘AppManager’)
#21 /opt/bitnami/apps/owncloud/htdocs/lib/private/Server.php(1359): OC\ServerContainer->query(‘AppManager’)
#22 /opt/bitnami/apps/owncloud/htdocs/lib/private/legacy/app.php(346): OC\Server->getAppManager()
#23 /opt/bitnami/apps/owncloud/htdocs/lib/private/legacy/app.php(110): OC_App::getEnabledApps()
#24 /opt/bitnami/apps/owncloud/htdocs/lib/base.php(579): OC_App::loadApps(Array)
#25 /opt/bitnami/apps/owncloud/htdocs/lib/base.php(998): OC::init()
#26 /opt/bitnami/apps/owncloud/htdocs/index.php(54): require_once(’/opt/bitnami/ap…’)
#27 {main}
Server configuration:
Operating system:
Debian (9)
Web server:
Apache (2.4.29)
Database:
MySQL (5.7.21)
PHP version:
PHP (7.0.28)
ownCloud version: (see ownCloud admin page)
ownCloud (10.0.7)
The content of config/config.php:
$CONFIG = array ( ‘passwordsalt’ => ‘#####’,
‘secret’ => ‘########’,
‘trusted_domains’ => array ( 0 => ‘127.0.0.1’, 1 => ‘35.194.21.102’, 2 => ‘####.org’, ),
‘datadirectory’ => ‘/opt/bitnami/apps/owncloud/data’,
‘overwrite.cli.url’ => ‘http://localhost’,
‘dbtype’ => ‘mysql’,
‘version’ => ‘10.0.7.2’,
‘dbname’ => ‘b######’,
‘dbhost’ => ‘127.0.0.1:/opt/bitnami/mysql/tmp/mysql.sock’,
‘dbtableprefix’ => 'oc’,
‘mysql.utf8mb4’ => true,
‘dbuser’ => ‘b#_####’,
‘dbpassword’ => ‘#####’,
‘logtimezone’ => ‘UTC’,
‘installed’ => true,
‘instanceid’ => ‘#####’,
‘openssl’ => array ( ‘config’ => ‘/opt/bitnami/common/openssl/openssl.cnf’, ),
I had similar problems when I used Owncloud in the past. It often crashed the database. The issues went away for me when I switched to Nextcloud. I hope this helps.
yii2-elasticsearch 2.1 not working with AWS elasticsearch
I want to use elasticsearch yii2 component with AWS elasticsearch service. But it is surly not allowing. Because AWS elasticsearch is not providing [http][publish_address] in response while electing node for connection. And yii2-elasticsearch(2.1) is simply discarding any such node.
Is there any other way, if i'm missing something?
Following is my component configuration and error i'm getting.
'elasticsearch' => [
'class' => 'yii\elasticsearch\Connection',
'nodes' => [
[
'http_address' => 'end-point.es.amazonaws.com',
'protocol' => 'https'
],
],
]
Stack trace:
#0 /var/www/html/staging/vendor/yiisoft/yii2-elasticsearch/Connection.php(190): yii\base\ErrorHandler->handleError(8, 'Undefined index...', '/var/www/html/s...', 190, Array)
#1 /var/www/html/staging/vendor/yiisoft/yii2-elasticsearch/Connection.php(155): yii\elasticsearch\Connection->populateNodes()
#2 /var/www/html/staging/vendor/yiisoft/yii2-elasticsearch/Connection.php(259): yii\elasticsearch\Connection->open()
#3 /var/www/html/staging/common/models/es/BaseModel.php(129): yii\elasticsearch\Connection->createCommand()
#4 /var/www/html/staging/common/models/es/BaseModel.php(134): common\models\es\BaseModel::deleteIndex()
#5 /var/www/html/staging/console/controllers/EsController.php(114): common\models\es\BaseModel::resetIndex()
#6 /var/www/html/staging/console/controllers/EsController.php(206): console\controllers\EsController->reindexInBulk(Array, '100')
#7 [internal function]: console\controllers\EsController->actionReindex()
#8 /var/www/html/staging/vendor/yiisoft/yii2/base/InlineAction.php(57): call_user_func_array(Array, Array)
#9 /var/www/html/staging/vendor/yiisoft/yii2/base/Controller.php(157): yii\base\InlineAction->runWithParams(Array)
#10 /var/www/html/staging/vendor/yiisoft/yii2/console/Controller.php(148): yii\base\Controller->runAction('reindex', Array)
#11 /var/www/html/staging/vendor/yiisoft/yii2/base/Module.php(528): yii\console\Controller->runAction('reindex', Array)
#12 /var/www/html/staging/vendor/yiisoft/yii2/console/Application.php(180): yii\base\Module->runAction('es/reindex', Array)
#13 /var/www/html/staging/vendor/yiisoft/yii2/console/Application.php(147): yii\console\Application->runAction('es/reindex', Array)
#14 /var/www/html/staging/vendor/yiisoft/yii2/base/Application.php(386): yii\console\Application->handleRequest(Object(yii\console\Request))
#15 /var/www/html/staging/yii(31): yii\base\Application->run()
#16 {main}
Look like it tries to delete an index that doesnt exist. /var/www/html/staging/common/models/es/BaseModel.php(134): common\models\es\BaseModel::deleteIndex() Hence the error.
How to identify the full command that caused the crash from the core dump file
There is a problem to identify the full command from the core dump file using gdb The crashed command itself can be long i.e. myCommand -f log/SlaRunTimeReport.rep -I input/myFile.txt -t output/myFile.txt But When using gdb to identify the command in the location “Core was generated by” i.e. by executing gdb -c core.56536 The Output: GNU gdb (GDB) Red Hat Enterprise Linux 7.10-20.el7 …. Core was generated by `myCommand -f log/SlaRunTimeReport.rep -I input/myFile.t'. It is possible to see that the full command(executable + parameters) was cut in the middle ‘myCommand -f log/SlaRunTimeReport.rep -I input/myFile.t' In additional using strings command , also did not help to identify the full command strings core.56536 | grep PMRunTimeReport The Output: myCommand myCommand -f log/SlaRunTimeReport.rep -I input/myFile.t Is there any way to get from coredump file the full command that caused the failure Thanks in Advance
Is there any way to get from coredump file the full command that caused the failure
There are multiple ways, but running strings is the wrong way.
IF you built your program with debug info, you should be able to simply execute up command until you reach main, then examine argv[0] through argv[argc-1].
If your main was not built with debug info, or if it doesn't use argc and argv, you should be able to recover that info from __libc_argc and __libc_argv variables. Example:
$ ./a.out foo bar baz $(python -c 'print "a" * 500')
Aborted (core dumped)
$ gdb -q ./a.out core
Core was generated by `./a.out foo bar baz aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'.
Note that the "generated by" is truncated -- it comes from a fixed length array inside of struct prpsinfo, saved in NT_PRPSINFO ELF note in the core.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007fab38cfcf2b in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install glibc-2.27-15.fc28.x86_64
(gdb) p (int)__libc_argc
$1 = 5
(gdb) p ((char**)__libc_argv)[0]#5
$2 = {0x7ffede43289f "./a.out", 0x7ffede4328a7 "foo", 0x7ffede4328ab "bar",
0x7ffede4328af "baz",
0x7ffede4328b3 'a' <repeats 200 times>...}
This last line is actually a lie -- we know that 'a' repeats 500 times.
We can fix it like so:
(gdb) set print elem 0
(gdb) p ((char**)__libc_argv)[0]#5
$3 = {0x7ffede43289f "./a.out", 0x7ffede4328a7 "foo", 0x7ffede4328ab "bar",
0x7ffede4328af "baz",
0x7ffede4328b3 'a' <repeats 500 times>}
Voila: we now have the complete command.
Lastly, if you install debug info for GLIBC, you can simply look in the __libc_start_main (which called your main):
(gdb) set backtrace past-main
(gdb) bt
#0 __GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007fab38ce7561 in __GI_abort () at abort.c:79
#2 0x00000000004004ef in main () at foo.c:3
#3 0x00007fab38ce918b in __libc_start_main (main=0x4004e6 <main>, argc=5, argv=0x7ffede431118,
init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffede431108)
at ../csu/libc-start.c:308
#4 0x000000000040042a in _start ()
Here you can clearly see argc and argv in frame 3, and can examine that argv like so:
(gdb) fr 3
#3 0x00007fab38ce918b in __libc_start_main (main=0x4004e6 <main>, argc=5, argv=0x7ffede431118,
init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffede431108)
at ../csu/libc-start.c:308
308 result = main (argc, argv, __environ MAIN_AUXVEC_PARAM);
(gdb) p argv[0]#5
$1 = {0x7ffede43289f "./a.out", 0x7ffede4328a7 "foo", 0x7ffede4328ab "bar",
0x7ffede4328af "baz",
0x7ffede4328b3 'a' <repeats 500 times>}
Sub process execution failing with std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string
I am trying to execute a binary(my_binary) from a python script abc.py as following. import os import sys import logging from subprocess import Popen, PIPE logging.basicConfig(level=logging.DEBUG,format='%(asctime)s % (levelname)-8s %(message)s',datefmt='%a, %d %b %Y %H:%M:%S',filename='/var/home/root/root.txt',filemode='w') os.environ["ABCDE"]="x.x.x.x" os.environ["USER"]="user" os.environ["PASSWORD"]="password" p1 = Popen(["/var/home/root/my_binary","exec"], stdout=PIPE, stderr=PIPE) out, err=p1.communicate() logging.info(out) return out,err if __name__ == '__main__': out,err = run(sys.argv[1:]) logging.info(out) if( out.strip() == "Success: Check:"): print "Success: OK:" If I execute this abc.py python program directly on the terminal, the binary my_binary will get executed. But when I am trying to run the program from another c++ (using pipe in a similar way as above) program(say xyz.cpp), my_binary is failing to execute. Note: The xyz.cpp is built with gcc(libstdc++.so.7). The my_binary is built with gcc(libstdc++.so.6). my_binary is built with "-D_GLIBCXX_USE_CXX11_ABI=0" as the .so used in my_binary are built using older g++(v 4.5). The ldd o/p for my_binary linux-vdso.so.1 => (0x00007fff2c9ff000) libx.so.0 => /opt/lib/libx.so.0 (0x00007f6caa7f6000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f6caa5d9000) libstdc++.so.6 => /opt/lib/libstdc++.so.6 (0x00007f6caa4be000) libm.so.6 => /lib64/libm.so.6 (0x00007f6caa23a000) libgcc_s.so.1 => /opt/lib/libgcc_s.so.1 (0x00007f6caa224000) libc.so.6 => /lib64/libc.so.6 (0x00007f6ca9e8f000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f6ca9c8b000) /lib64/ld-linux-x86-64.so.2 (0x00007f6cab1e0000) ldd o/p for xyz.cpp linux-vdso.so.1 => (0x00007fff62dff000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3b736af000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f3b734ab000) libz.so.1 => /lib64/libz.so.1 (0x00007f3b72dc2000) libstdc++.so.7 => /opt/lib64/libstdc++.so.7 (0x00007f3b7204e000) libm.so.6 => /lib64/libm.so.6 (0x00007f3b71dc9000) libgcc_s.so.1 => /opt/lib64/libgcc_s.so.1 (0x00007f3b71db2000) libc.so.6 => /lib64/libc.so.6 (0x00007f3b71a1e000) /lib64/ld-linux-x86-64.so.2 (0x00007f3b738d2000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f3b70a73000) objdump -T my_binary|fgrep GLIBC GLIBCXX_3.4 GLIBC_2.2.5 GLIBC_2.4 objdump -T xyz.cpp|fgrep GLIBC GLIBC_2.3.2 GLIBC_2.2.5 GLIBCXX_7.0 The backtrace is: (gdb) bt #0 0x00007f80a3f39495 in raise () from /lib64/libc.so.6 #1 0x00007f80a3f3ac75 in abort () from /lib64/libc.so.6 #2 0x00007f80a528a0d5 in __gnu_cxx::__verbose_terminate_handler() () from /opt/lib/libstdc++.so.6 #3 0x00007f80a5288166 in ?? () from /opt/lib/libstdc++.so.6 #4 0x00007f80a5288193 in std::terminate() () from /opt/lib/libstdc++.so.6 #5 0x00007f80a52883e6 in __cxa_throw () from /opt/lib/libstdc++.so.6 #6 0x00007f80a52e3262 in std::__throw_logic_error(char const*) () from /opt/lib/libstdc++.so.6 #7 0x00007f80a52ef6f1 in char* std::string::_S_construct<char const*> (char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) () from /opt/lib/libstdc++.so.6 #8 0x00007f80a52efac8 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) () from /opt/lib/libstdc++.so.6 All the required shared as well as static libraries are present in the env. Any help would be appreciated. Thanks.
Qt QTest segmentation fault at end of execution
I have a small test programs that talks to a server backend through a library that I have written. The test uses the QTest framework and runs through a bunch of test cases. The latest version of the test program has started to issue a segmentation fault after all of my tests have run. The output is something like:
********* Start testing of TestSequence *********
Config: Using QtTest library 5.6.1, Qt 5.6.1 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 4.9.1 20140922 (Red Hat 4.9.1-10))
...
Totals: 28 passed, 0 failed, 0 skipped, 0 blacklisted
********* Finished testing of TestSequence *********
RUN FINISHED; Segmentation fault; core dumped; real time: 26s; user: 40ms; system: 290ms
I can get a stack backtrace from the segfault:
#0 0x00007fffe9b3a61e in QDBusMetaType::typeToSignature(int) () from /home/pete/Qt/5.6/gcc_64/plugins/bearer/../../lib/libQt5DBus.so.5
No symbol table info available.
#1 0x00007fffe9b31a9e in qDBusParametersForMethod(QList<QByteArray> const&, QVector<int>&, QString&) () from /home/pete/Qt/5.6/gcc_64/plugins/bearer/../../lib/libQt5DBus.so.5
No symbol table info available.
#2 0x00007fffe9b31fc9 in ?? () from /home/pete/Qt/5.6/gcc_64/plugins/bearer/../../lib/libQt5DBus.so.5
No symbol table info available.
#3 0x00007fffe9aff081 in ?? () from /home/pete/Qt/5.6/gcc_64/plugins/bearer/../../lib/libQt5DBus.so.5
No symbol table info available.
#4 0x00007fffe9aff8bf in ?? () from /home/pete/Qt/5.6/gcc_64/plugins/bearer/../../lib/libQt5DBus.so.5
No symbol table info available.
#5 0x00007fffe9b005c6 in ?? () from /home/pete/Qt/5.6/gcc_64/plugins/bearer/../../lib/libQt5DBus.so.5
No symbol table info available.
#6 0x00007fffe9b115af in ?? () from /home/pete/Qt/5.6/gcc_64/plugins/bearer/../../lib/libQt5DBus.so.5
No symbol table info available.
#7 0x00007ffff626cf7a in QObject::event(QEvent*) () from /home/pete/Qt/5.6/gcc_64/lib/libQt5Core.so.5
No symbol table info available.
#8 0x00007ffff6242b6b in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /home/pete/Qt/5.6/gcc_64/lib/libQt5Core.so.5
No symbol table info available.
#9 0x00007ffff6245373 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /home/pete/Qt/5.6/gcc_64/lib/libQt5Core.so.5
No symbol table info available.
#10 0x00007ffff6291d83 in ?? () from /home/pete/Qt/5.6/gcc_64/lib/libQt5Core.so.5
No symbol table info available.
#11 0x00007ffff45f6e04 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#12 0x00007ffff45f7048 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#13 0x00007ffff45f70ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#14 0x00007ffff6292177 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /home/pete/Qt/5.6/gcc_64/lib/libQt5Core.so.5
No symbol table info available.
#15 0x00007ffff6240bca in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /home/pete/Qt/5.6/gcc_64/lib/libQt5Core.so.5
No symbol table info available.
#16 0x00007ffff607ae4c in QThread::exec() () from /home/pete/Qt/5.6/gcc_64/lib/libQt5Core.so.5
No symbol table info available.
#17 0x00007ffff607f769 in ?? () from /home/pete/Qt/5.6/gcc_64/lib/libQt5Core.so.5
No symbol table info available.
#18 0x00007ffff4f19182 in start_thread (arg=0x7fffea796700) at pthread_create.c:312
__res = <optimised out>
pd = 0x7fffea796700
now = <optimised out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737127212800, -4443015154407963459, 1, 0, 140737127213504, 140737127212800, 4443057989164074173, 4443034828799739069}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimised out>
pagesize_m1 = <optimised out>
sp = <optimised out>
freesize = <optimised out>
__PRETTY_FUNCTION__ = \"start_thread\"
#19 0x00007ffff57f047d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
No locals.
This looks like the fault is outside my code, but presumably something I've done has caused it!
Any insight from the crowd? Or should I report a bug to Qt?
Your problem seems to be related to this bug that affects Qt 5.6. As mentioned in the trail of comments, it should have been solved in Qt 5.7. You can also apply a few patches to solve it on version 5.6. The discussion is dated 6/2016 and lasts at the end of September.