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] [source]

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 Warren Young (tangent) on 2018-08-22 04:03:19 in reply to 1 [source]

#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

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.