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
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
