Got signal 11, Segmentation fault core dump issue after upgrade MySQL client from 5.6.18 to 5.6.41 and mysql++ from 3.1.0 to 3.2.3.
(1) By anonymous on 2018-08-17 12:54:05 [link]
Hi All, We are getting signal 11, Segmentation fault core dump issue after upgrade MySQL client from 5.6.18 to 5.6.41 and mysql++ from 3.1.0 to 3.2.3. Previously my top layer MySQL application running fine with older release version of MySQL and mysql++. Following backtrace report Program terminated with signal 11, Segmentation fault. #0 0x005cc978 in mysqlpp::DBDriver::~DBDriver (this=0x8ef2c00, __in_chrg=<value optimized out>) at /media2/7_12_new/css-vsms/server/gpl/mysql-plusplus-3.2.3/lib/dbdriver.cpp:71 #1 0x005c5c5a in mysqlpp::Connection::~Connection (this=0x8ef2110, __in_chrg=<value optimized out>) at /media2/7_12_new/css-vsms/server/gpl/mysql-plusplus-3.2.3/lib/connection.cpp:75 #2 0x01e6f072 in umsConnectionPool::destroy (this=0x21163a8, cp=0x8ef2110) at /media2/7_12_new/css-vsms/server/applications/mysql++/src/dbInterface.cxx:36 #3 0x005c98c2 in mysqlpp::ConnectionPool::remove (this=0x21163a8, it=...) at /media2/7_12_new/css-vsms/server/gpl/mysql-plusplus-3.1.0/lib/cpool.cpp:187 #4 0x005c9972 in mysqlpp::ConnectionPool::remove_old_connections (this=0x21163a8) at /media2/7_12_new/css-vsms/server/gpl/mysql-plusplus-3.1.0/lib/cpool.cpp:202 #5 0x005c9dad in mysqlpp::ConnectionPool::grab (this=0x21163a8) at /media2/7_12_new/css-vsms/server/gpl/mysql-plusplus-3.1.0/lib/cpool.cpp:129 #6 0x01e6ea87 in ScopedConnection::ScopedConnection (this=0xf61fde64, conn=0x0, transaction=false) at /media2/7_12_new/css-vsms/server/applications/mysql++/src/dbInterface.cxx:86 #7 0x01ea8340 in dbHAServerAssociation::getDeviceServerAssociations (server_uid="1c44c319-a1dd-11e8-bd00-000c29deb838", pConn=0x0) at /media2/7_12_new/css-vsms/server/applications/mysql++/src/dbFailover.cxx:540 #8 0x01b01686 in CoolHAServers::getHAServers (serverUid="1c44c319-a1dd-11e8-bd00-000c29deb838", primary=false) at /media2/7_12_new/css-vsms/server/applications/cool/CoolHighAvail.cxx:615 #9 0x02234966 in getServers (servers=std::map with 0 elements, primary=false) at /media2/7_12_new/css-vsms/server/bms/src/programs/failover/FailoverServer.cxx:24 #10 0x02234c52 in FailoverServer::getFailoverServers (servers=std::map with 0 elements) at /media2/7_12_new/css-vsms/server/bms/src/programs/failover/FailoverServer.cxx:1009 #11 0x02235736 in FailoverServerMonitor::run (this=0x8f0fa78) at /media2/7_12_new/css-vsms/server/bms/src/programs/failover/FailoverServer.cxx:614 #12 0x003b158f in LThread::start_thread (obj=0x8f0fa78) at /media2/7_12_new/css-vsms/server/bms/src/libs/util/LThread.cxx:19 #13 0x00d3bbc9 in start_thread () from /lib/libpthread.so.0 #14 0x04a3a07e in clone () from /lib/libc.so.6 Regards Pankaj
(2) By tangent on 2018-08-22 04:03:19 in reply to 1
#0 0x005cc978 in mysqlpp::DBDriver::~DBDriver (this=0x8ef2c00, __in_chrg=
) at /media2/7_12_new/css-vsms/server/gpl/mysql-plusplus-3.2.3/lib/dbdriver.cpp:71
That line is a
delete for an object that MySQL++ itself allocated. Since we can be pretty sure that MySQL++ is not deleting objects it doesn't own, that means you've probably done something like cause MySQL++ to double-delete one of its own objects.
#13 0x00d3bbc9 in start_thread () from /lib/libpthread.so.0
That supports my guess. Have you read the threading chapter in the user manual? And if so, have you re-read it recently?
Incidentally, MySQL++ 3.2.4 is out. I suspect part of your problem is that you're not building from source — else why are you using an older version? — and the one who built your libraries did not do so with thread awareness enabled. If so, you're going to need to build from source anyway.