Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Not a Bug
-
None
-
None
-
None
-
Gentoo Linux; MariaDB 10.2.9
Description
This bug is easily demonstrated by running the Perl DBD-mysql tests.
Backtrace:
#0 0x0000110600000001 in ?? ()
|
#1 0x00007ffff5a41779 in mariadb_reconnect (mysql=0x5555560b2a40)
|
at /var/tmp/portage/dev-db/mariadb-10.2.9/work/mysql/libmariadb/libmariadb/mariadb_lib.c:1593
|
#2 0x00007ffff5a41d9a in mthd_my_send_cmd (mysql=0x5555560b2a40, command=COM_STMT_PREPARE, arg=0x55555577c3c0 "SELECT 1", length=8,
|
skipp_check=<optimized out>, opt_arg=0x5555560b7e50) at /var/tmp/portage/dev-db/mariadb-10.2.9/work/mysql/libmariadb/libmariadb/mariadb_lib.c:365
|
#3 0x00007ffff5a49c91 in mysql_stmt_prepare (stmt=stmt@entry=0x5555560b7e50, query=query@entry=0x55555577c3c0 "SELECT 1", length=8)
|
at /var/tmp/portage/dev-db/mariadb-10.2.9/work/mysql/libmariadb/libmariadb/mariadb_stmt.c:1571
|
#4 0x00007ffff5c7e9d4 in XS_DBD__mysql__db_do (cv=<optimized out>) at mysql.xs:342
|
#5 0x00007ffff5e9f93c in XS_DBI_dispatch () from /usr/lib64/perl5/vendor_perl/5.26.1/x86_64-linux/auto/DBI/DBI.so
|
#6 0x00007ffff7ac2153 in Perl_pp_entersub () from /usr/lib64/libperl.so.5.26
|
#7 0x00007ffff7ab9c83 in Perl_runops_standard () from /usr/lib64/libperl.so.5.26
|
#8 0x00007ffff7a44be3 in perl_run () from /usr/lib64/libperl.so.5.26
|
#9 0x0000555555554e0b in main ()
|
Attachments
Activity
The bug is in the DBD-mysql driver:
Perl keeps a copy of the mysql handle, set socket to invalid and calls mysql_close().
mysql_close() }}doesn't free the mysql handle only, but also {{mysql->options.extension, mysql->net.extension and mysql->extension. When reconnecting the driver is reusing the copy of the mysql handle, which has pointers which point into nirvana.
Another good example why not abusing internals.
I'm already talking to the DBD-mysql maintainers how to fix that.
Hi,
I was asked to look into this. While arguably it's a DBD::mysql bug, I think that mysql_close() should set mysql->net.extension and mysql->extension to NULL after it frees them. This is just good defensive programming practice.
The attached patch seems to fix the bug reported at https://github.com/perl5-dbi/DBD-mysql/issues/306 null-out-freed-pointers-in-mysql-close.patch
I'm able to reproduce this issue, however this is a bug in DBD-mysql or 15reconnect test.
1) the test calls mysql_close():
mysql_close (mysql=0xcfdcb0) at /home/georg/work/mariadb/connector/cc_main/libmariadb/mariadb_lib.c:19132) the test calls mysql_real_query() with the same handle:
mysql_real_query (mysql=0xcfdcb0, query=0xa588c0 "SELECT 1", length=8) at /home/georg/work/mariadb/connector/cc_main/libmariadb/mariadb_lib.c:2171According to the documentation mysql handle has to be initialized by mysql_init()/mysql_real_connect() before, but it was already freed by mysql_close(). That it doesn't crash with libmysql from 10.1 is just concidence: If you do some memory allocations between mysql_close() and mysql_real_query() the freed memory will be overwritten and lead to crashes or unexpected results. Also valgrind reports a lot of invalid reads when running 15reconnect.t