maria-developers team mailing list archive

[Ma Allen <mazhh@xxxxxxxxxxx>]

Hi Markus,

Only MySqlWaitConnected() in the two functions doesn't use lock, reading database uses mutex. What's more, the two functions in initialization relates to ONLY the main thread. No other threads call them.

Previously, the program is written with mysqllib, which is not MariaDB lib currently used. Mysqllib supports multiple threads to concurrently use one connection. Its tutorials were also referred to:
https://dev.mysql.com/doc/refman/5.7/en/c-api-threaded-clients.html

MySQL :: MySQL 5.7 Reference Manual :: 27.7.3.3 Writing C API Threaded Client Programs<https://dev.mysql.com/doc/refman/5.7/en/c-api-threaded-clients.html>
This section provides guidance for writing client programs that use the thread-related functions in the MySQL C API. For further information about these functions, see Section 27.7.11, “C API Threaded Function Descriptions”.For examples of source code that uses them, look in the client directory of a MySQL source distribution:
dev.mysql.com

After replacing mysqllib with MariaDB lib, everything works well on the test environment except one of the clients'.

Allen

________________________________
发件人: Maria-discuss <maria-discuss-bounces+mazhh=outlook.com@xxxxxxxxxxxxxxxxxxx> 代表 Markus Mäkelä <markus.makela@xxxxxxxxxxx>
发送时间: 2020年1月14日 15:40
收件人: maria-discuss@xxxxxxxxxxxxxxxxxxx <maria-discuss@xxxxxxxxxxxxxxxxxxx>
主题: Re: [Maria-discuss] [Maria-developers] [MariaDB 10.3.7] Hello, everyone. My process core dumped while calling mysql_ping().


Hi,


Is the connection protected by a lock of some sorts? To my knowledge the library does not support concurrent use of a single connection. I'd recommend trying to first wrap all access to the connection with a mutex and see if that solves the problem.


Markus


On 1/14/20 08:33, Ma Allen wrote:
Environment:
MariaDB 10.3.7 database server & related headers and libraries
CentOS 7.3 or 7.4

./configure --prefix=/home/spiderflow --localstatedir=/home/spiderflow --enable-unix-socket --with-libnss-libraries=/usr/lib64 --with-libnss-includes=/usr/include/nss3 --with-libnspr-libraries=/usr/lib64 --with-libnspr-includes=/usr/include/nspr4 --enable-netmap --enable-rust --disable-gccmarch-native --enable-mysql --with-libmysql-includes=/usr/local/mariadb-10.3.7-linux-systemd-x86_64/include/mysql --with-libmysql-libraries=/usr/local/mariadb-10.3.7-linux-systemd-x86_64/lib

Phenomenon:
(gdb)
#0  ma_pvio_write (pvio=0x10101010101b2e0, buffer=buffer@entry=0x2510101 "\001", length=length@entry=5)​
    at /home/buildbot/buildbot/build/libmariadb/libmariadb/ma_pvio.c:350​
#1  0x00007f7100249dea in ma_net_real_write (net=net@entry=0xee9de0 <g_mysql_info>, packet=0x2510101 "\001", len=5)​
    at /home/buildbot/buildbot/build/libmariadb/libmariadb/ma_net.c:335​
#2  0x00007f7100249f60 in ma_net_flush (net=net@entry=0xee9de0 <g_mysql_info>) at /home/buildbot/buildbot/build/libmariadb/libmariadb/ma_net.c:166​
#3  0x00007f710024a71a in ma_net_write_command (net=net@entry=0xee9de0 <g_mysql_info>, command=command@entry=14 '\016', packet=packet@entry=0x7f71003d6c67 "", len=0, ​
    disable_flush=disable_flush@entry=0 '\000') at /home/buildbot/buildbot/build/libmariadb/libmariadb/ma_net.c:244​
#4  0x00007f7100252ca4 in mthd_my_send_cmd (mysql=0xee9de0 <g_mysql_info>, command=<optimized out>, arg=0x7f71003d6c67 "", length=0, skipp_check=<optimized out>, ​
    opt_arg=<optimized out>) at /home/buildbot/buildbot/build/libmariadb/libmariadb/mariadb_lib.c:394​
#5  0x00007f71002518d0 in mysql_ping (mysql=0xee9de0 <g_mysql_info>) at /home/buildbot/buildbot/build/libmariadb/libmariadb/mariadb_lib.c:2552​
#6  0x00000000006651b2 in MySqlWaitConnected (p_mysql_data=p_mysql_data@entry=0xee9de0 <g_mysql_info>) at ../srcSF/spiderFlow-proto-baseline.c:676​
#7  0x0000000000668819 in LoadProtoConfInfos (pInfo=pInfo@entry=0xee9de0 <g_mysql_info>) at ../srcSF/spiderFlow-proto-baseline.c:835​
#8  0x000000000066c53a in InitBaseLine () at ../srcSF/spiderFlow-proto-baseline.c:1069​
#9  0x00000000005f308b in PostConfLoadedSetup (suri=0x10dbb80 <suricata>) at suricata.c:2900​
#10 0x0000000000425ce8 in main (argc=5, argv=0x7fff1cdca258) at suricata.c:3072​
(gdb)

Analyzation:
The core dump always exists after running for a while or maybe after the sever restarts. It occurs at the initialization and involves with ONLY ONE thread, which is the main thread of the whole process.
The related code is two functions, which both checks the connection and read data from MariaDB. The first function works fine, however, the second one's checking connection leads to core dump.

The code to check connection is as follows:
void MySqlWaitConnected(MYSQL * p_mysql_data)
{​​
while (mysql_ping(p_mysql_data) != 0) {​
SCLogInfo("Mysql ping error:%s", mysql_error(p_mysql_data));​
#ifdef WIN32​
Sleep(3000);​
#else​
sleep(3);​
#endif​
}​
}​

Previously, I solved a likely similar problem as follows:
Multiple threads shared ONE MySQL handler, which is the MYSQL data structure. Before inserting data into MariaDB without mutex, MySqlWaitConnected() is called. So while multiple threads do the same operation, inserting data is interrupted by mysql_ping() that leads to core dump. Afterwards, I comment MySqlWaitConnected() and add mutex for mysql_real_query() and mysql_commit().

Does anyone meet the same problem before? Any suggestion is appreciated. Thanks in advance.

Best Regards,
Allen Ma



_______________________________________________
Mailing list: https://launchpad.net/~maria-developers
Post to     : maria-developers@xxxxxxxxxxxxxxxxxxx<mailto:maria-developers@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp


--
Markus Mäkelä, Senior Software Engineer
MariaDB Corporation
t: +358 40 7740484 | IRC: markusjm@freenode