MySQL++

free() error with MySQL++ 3.2.5 and MySQL 8.018
Login

free() error with MySQL++ 3.2.5 and MySQL 8.018

(1) By Armin (nollarm) on 2019-12-03 07:49:55 [link]

Dear team,

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 ?

Regards
Armin

(2) By Warren Young (tangent) on 2019-12-03 13:08:14 in reply to 1

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 `libcrypto`, bypassing `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](https://linux.die.net/man/1/addr2line) to decode those addresses so we can at least see where you're stepping out of MySQL++ into `libcrypto`.