Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Incomplete
-
10.2.5, 10.2.6
-
Arch Linux
-
10.2.7-1
Description
MariaDB 10.2.x (including current stable version 10.2.6) ships with new libmariadb. This new client library is built with new header files mariadb_*.h.
When compiling clients these are linked against new libmariadb, but use old header file mysql.h that is still shipped.
The header files use conflicting data definitions. One example is struct st_mysql_stmt, defined in mysql.h at line 723 and mariadb_stmt.h at line 193. Possibly there are more conflicts.
These conflicting data definitions lead to memory corruption, illegal memory access and crashes for the client. This has been discovered with perl-dbd-mysql where lots of tests fail with make test.
Attachments
Activity
Another header is present in both locations, errmsg.h, and depending on the installation order either copy can get installed. (By installation order we mean whether we run "make install" in include/ or libmariadb/ first.)
Ideally both headers (mysql.h, errmsg.h) would exist in a single location (seems like that should be under libmariadb/include/).
struct st_mysql_stmt or MYSQL_STMT needs to be allocated via mysql_stmt_init() function. In the past the structure changed several times without bumping the .so number (e.g. prefetch_rows member)
If Perl access internal members of st_mysql_stmt, it should be filed as a bug in Perl. See also
If MYSQL_STMT is considered unstable (in regards of API stability) why do you expose it in public header files?
Instead you should make it private. A lot of projects will blame you for breaking things, but in the end it will make things better.
(OpenSSL had/has the same with release 1.1.0...)
Christian,
I fully agree that having opaque data structures should be the right way. Since 10.2.6 MariaDB Server also supports OpenSSL 1.1, but it required a lot changes (and also some dirty hacking).
Making MYSQL_STMT structure opaque shouldn't cause major problems, but making MYSQL, MYSQL_FIELD and friends opaque might break a lot of programs, e.g.
MYSQL mysql= mysql_init(NULL); /* this should be ok */ |
|
|
MYSQL mysql;
|
mysql_init(&mysql); /* This would not work anymore */ |
I will put this topic on the agenda for our next team meeting.
Is this still an issue? After MDEV-13370 client's (libmariadb's) and server's mysql.h are installed in different locations. Clients and connectors should not include server's version of mysql.h, so there should be no data type conflicts.
We have updated the package from 10.1.37 to 10.3.12. So the issue has been resolved any time between 10.2.6 and 10.3.12. Thanks and please close!
Edit: Just noticed it is closed already, so sorry for the noise.
Looks like our packaging is at least part of the issue:
MariaDB 10.2.6 has two versions of mysql.h (include/mysql.h and libmariadb/include/mysql.h), depending on the install order you will end up with the wrong or correct one. Please purge the wrong one from repositories and tarballs.
Having the correct version of mysql.h brings up another problem: mysql_version.h is no longer included, thus MYSQL_VERSION_ID is not defined. Is that by intention? A lot of packages fail to build without that define.