[MDEV-12935] conflicting data types, crashing clients Created: 2017-05-27  Updated: 2019-02-01  Resolved: 2017-12-11

Status: Closed
Project: MariaDB Server
Component/s: Compiling
Affects Version/s: 10.2.5, 10.2.6
Fix Version/s: N/A

Type: Bug Priority: Critical
Reporter: Christian Hesse Assignee: Georg Richter
Resolution: Incomplete Votes: 0
Labels: libmariadb, need_feedback
Environment:

Arch Linux

Sprint: 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.

 Comments   
Comment by Christian Hesse [ 2017-05-27 ]

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.

Comment by Evangelos Foutras [ 2017-05-27 ]

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/).

Comment by Georg Richter [ 2017-06-21 ]

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

Comment by Christian Hesse [ 2017-08-03 ]

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...)

Comment by Georg Richter [ 2017-08-04 ]

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.

Comment by Sergei Golubchik [ 2017-10-04 ]

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.

Comment by Christian Hesse [ 2019-02-01 ]

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.

Generated at Thu Feb 08 08:01:38 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.