free() error with MySQL++ 3.2.5 and MySQL 8.018
(1) By Armin (nollarm) on 2019-12-03 07:49:55 [source]
we built our application with MySQL++ 3.2.5 and MySQL 8.0.18 under RHEL 7.6. When running it, we get the following error more or less immediately:
.*** Error in `bosd': free(): invalid next size (fast): 0x00000000032c64e0 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x81489)[0x7f9521f51489] /opt/gts/3pp/mysql/lib/libcrypto.so.1.1(CRYPTO_free+0x29)[0x7f951f31b8b5] /opt/gts/3pp/mysql/lib/libcrypto.so.1.1(CRYPTO_clear_free+0x3a)[0x7f951f31b8f1] /opt/gts/3pp/mysql/lib/libcrypto.so.1.1(EVP_MD_CTX_reset+0x7d)[0x7f951f3007e1] /opt/gts/3pp/mysql/lib/libcrypto.so.1.1(EVP_MD_CTX_free+0x11)[0x7f951f300a97] /opt/gts/3pp/usr/lib64/libmysqlpp.so.3(_Z8scramblePcPKcS1_+0x36)[0x7f95244d68b6] /opt/gts/3pp/usr/lib64/libmysqlpp.so.3(+0xa2d0c)[0x7f95244c4d0c] /opt/gts/3pp/usr/lib64/libmysqlpp.so.3(+0xa7d19)[0x7f95244c9d19] /opt/gts/3pp/usr/lib64/libmysqlpp.so.3(run_plugin_auth+0x69)[0x7f95244cd0c9] /opt/gts/3pp/usr/lib64/libmysqlpp.so.3(+0xab2dc)[0x7f95244cd2dc] /opt/gts/3pp/usr/lib64/libmysqlpp.so.3(mysql_real_connect+0x89)[0x7f95244cee79] /opt/gts/3pp/usr/lib64/libmysqlpp.so.3(_ZN7mysqlpp8DBDriver7connectEPKcS2_jS2_S2_S2_+0x62)[0x7f952449ce42] /opt/gts/3pp/usr/lib64/libmysqlpp.so.3(_ZN7mysqlpp10Connection7connectEPKcS2_S2_S2_j+0xc2)[0x7f9524494ff2] /opt/gts/usr/lib64/libMySQLppWrapper.so.1.0(_ZN3gts6common7service14mysqlppwrapper14MySQLppWrapper6createEv+0xef)[0x7f95262f799f] /opt/gts/3pp/usr/lib64/libmysqlpp.so.3(_ZN7mysqlpp14ConnectionPool4grabEv+0x51)[0x7f952449a421] /opt/gts/usr/lib64/libMySQLppWrapper.so.1.0(_ZN3gts6common7service14mysqlppwrapper14MySQLppWrapper4initEiSsSsSsSsbbPNS2_13EventReceiverEiijj+0xb58)[0x7f95262f89d8] /opt/gts/usr/lib64/libMySQLppWrapper.so.1.0(_ZN3gts6common7service14mysqlppwrapper14MySQLppWrapper4initERKN7monitor24DatabaseConnectionParamsEbbPNS2_13EventReceiverE+0x101)[0x7f95262f9c81] bosd(_ZN3gts6common17controllermonitor3bos18ConfigServiceShell23HookBeforeMessagingInitEv+0x136)[0x71c016] /opt/gts/usr/lib64/libbaseshell.so.1.3(_ZN3gts6common5shell9BaseShell4InitEiPPKc+0x65)[0x7f95282a85f5] bosd(_ZN3gts6common17controllermonitor3bos18ConfigServiceShell4InitEiPPKc+0x23)[0x71e683] bosd(main+0xc3)[0x69d7e3] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f9521ef23d5] bosd[0x71785f] ======= Memory map: ======== 00400000-00db6000 r-xp 00000000 fd:02 13245817 /opt/gts/bin/bosd ...
The same with MySQL++ 3.2.4 and MySQL 5.7.27 works perfectly.
Do you have an idea what might be the problem? Might MySQL++ 3.2.5 not be compatible with MySQL 8.0.18 ?
As to your question of compatibility, I have no reason to believe current MySQL++ is incompatible with current MySQL. I'd need more than is in your post to change that belief. Indeed, it goes the other direction: the latest version of MySQL++ has specific changes to improve MySQL 8.0.x compatibility. Perhaps more changes are needed, but usually when that's the case, MySQL++ doesn't build at all.
free() is a C library function, which means it's well below the level of MySQL++, which generally avoids all C library mechanisms where there is a C++ equivalent. The string "
free(" doesn't even appear in the MySQL++ library code.
Your own stack trace shows this call happening several levels down in
libcrypto, which is of course not MySQL++ at all.
The only odd thing I see there is that we don't see
libmysqlclient in the call stack. I don't know how MySQL++ calls straight into
libmysqlclient. I'd guess there's a macro or inline function in the MySQL C API headers, but that's just a wild guess because you haven't provided any MySQL++ source code file names or line numbers.
Either run the program under a debugger with a debug build of the libraries so that you can get a more useful backtrace or use addr2line to decode those addresses so we can at least see where you're stepping out of MySQL++ into