Bug #88216 mysql_stmt_execute() fails on the performance_schema table
Submitted: 25 Oct 2017 4:12 Modified: 9 Jul 2018 15:11
Reporter: Igor Korot Email Updates:
Status: Verified Impact on me:
None 
Category:Connector / C Severity:S1 (Critical)
Version: OS:Linux
Assigned to: CPU Architecture:Any

[25 Oct 2017 4:12] Igor Korot
Description:
Hi,
Running following code against mySQL 5.6 on Gentoo Linux:

    std::wstring query3 = L"SELECT kcu.column_name, kcu.ordinal_position, kcu.referenced_table_schema, kcu.referenced_table_name, kcu.referenced_column_name, rc.update_rule, rc.delete_rule FROM information_schema.key_column_usage kcu, information_schema.referential_constraints rc WHERE kcu.constraint_name = rc.constraint_name AND kcu.table_catalog = ? AND kcu.table_schema = ? AND kcu.table_name = ?;";
    char *catalog_name = row[0] ? row[0] : NULL;
    char *schema_name = row[1] ? row[1] : NULL;
    char *table_name = row[2] ? row[2] : NULL;
    MYSQL_BIND params[3];
    unsigned long str_length1, str_length2, str_length3;
    str_length1 = strlen( catalog_name ) * 2;
    str_length2 = strlen( schema_name ) * 2;
    str_length3 = strlen( table_name ) * 2;
    str_data1 = new char[str_length1], str_data2 = new char[str_length2], str_data3 = new char[str_length3];
    memset( str_data1, '\0', str_length1 );
    memset( str_data2, '\0', str_length2 );
    memset( str_data3, '\0', str_length3 );
    memset( params, 0, sizeof( params ) );
    strncpy( str_data1, catalog_name, str_length1 );
    strncpy( str_data2, schema_name, str_length2 );
    strncpy( str_data3, table_name, str_length3 );
    params[0].buffer_type = MYSQL_TYPE_STRING;
    params[0].buffer = (char *) str_data1;
    params[0].buffer_length = strlen( str_data1 );
    params[0].is_null = 0;
    params[0].length = &str_length1;
    params[1].buffer_type = MYSQL_TYPE_STRING;
    params[1].buffer = (char *) str_data2;
    params[1].buffer_length = strlen( str_data2 );
    params[1].is_null = 0;
    params[1].length = &str_length2;
    params[2].buffer_type = MYSQL_TYPE_STRING;
    params[2].buffer = (char *) str_data3;
    params[2].buffer_length = strlen( str_data3 );
    params[2].is_null = 0;
    params[2].length = &str_length3;
    if( mysql_stmt_bind_param( res1, params ) )
    {
    std::wstring err = m_pimpl->m_myconv.from_bytes( mysql_stmt_error( res1 ) );
    errorMsg.push_back( err );
    result = 1;
    break;
    }
    else
    {
    prepare_meta_result = mysql_stmt_result_metadata( res1 );
    if( !prepare_meta_result )
    {
    std::wstring err = m_pimpl->m_myconv.from_bytes( mysql_stmt_error( res1 ) );
    errorMsg.push_back( err );
    result = 1;
    break;
    }
    else
    {
    if( mysql_stmt_execute( res1 ) )
    {
    std::wstring err = m_pimpl->m_myconv.from_bytes( mysql_stmt_error( res1 ) );
    errorMsg.push_back( err );
    result = 1;
    break;
    }

When the code tries to retrieve information about "performance_schema.events_stages_summary_by_account_by_event_name" mysql_stmt_execute() fails with the error "Identifier name 'events_stages_summary_by_account_by_event_name' is too long".

Using the latest version of connector/C compiled from source code.

The code works fine retrieving the information from my schema and "mysql" schema and some tables from "performance_schema".

The code shouldn't fail on this table and should continue execution. But even if not - the limit of 64 characters is not hit. Moreover the name in question is not identifier - it is a parameter to the query.

How to repeat:
Use the code in the description in the loop that retrieves catalog, schema and table name. When execution hits the table in question the error occur.
[25 Oct 2017 8:17] MySQL Verification Team
Please provide the complete test case ( C file code ). Thanks in advance.
[27 Oct 2017 0:28] Igor Korot
Sample code

Attachment: sample.cpp (text/x-c++src), 4.84 KiB.

[27 Oct 2017 0:30] Igor Korot
Execution log of the program

Attachment: sample_execution (application/octet-stream, text), 5.82 KiB.

[27 Oct 2017 0:34] Igor Korot
Attached is sample code, which demonstrates the issue.
Also attached is execution log of that program.

In order to compile you need to supply "-std=c++11".

Thank you for looking into this.
[28 Oct 2017 2:29] Igor Korot
Corrected memory leaks

Attachment: sample.cpp (text/x-c++src), 4.95 KiB.

[28 Oct 2017 2:32] Igor Korot
Draft schema

Attachment: draft.schema (application/octet-stream, text), 2.38 MiB.

[28 Oct 2017 2:33] Igor Korot
Attached is the version where I corrected memory leaks.
The results of execution is the same.

I also attached the draft schema for you check.

TIA!!!
[15 Jun 2018 11:54] Chiranjeevi Battula
Hello Igor,

Thank you for the bug report.
As per my internal discussion with Developers,  we would like to suggest you to use recent libmysqlclient instead and confirm to us if it still has this issue.

Thanks,
Chiranjeevi.
[29 Jun 2018 17:54] Igor Korot
Hi, Chiranjeevi,
[quote]
[15 Jun 11:54] Chiranjeevi Battula

Hello Igor,

Thank you for the bug report.
As per my internal discussion with Developers,  we would like to suggest you to use recent libmysqlclient instead and confirm to us if it still has this issue.

Thanks,
Chiranjeevi.
[/quote]

First of all, just curious - how long does it take to have an internal conversation with the Developers? Its been 6 month since I supply a complete test case scenario and just now someone responded.

Second of all - I can download the recent mySQL Connector/C and try it, but where is the guarantee that I get a reply immediately and not just in 6 month again or even worth - in a year?

Third, and most important, this library should be backward compatible, simply because not all *nix'es have their releases at the same time and not all developers are able to update to the latest OS and even more importantly - not all users can.

Now one question remains - are you able to reproduce the bug or not? Do you have a fix or not? And if you have a fix - is it already being applied and what version of Connector/C has it?

Thank you.
[3 Jul 2018 13:17] Chiranjeevi Battula
Hello Igor,

Thank you for your feedback.
Note that we do not actively support version 6.1 of Connector/C any more and this is why your report did not get as much attention as it should - sorry for that. But we are able to reproduce the same issue with the latest version of Connector/C (libmysqlclient).

Please be advised that version 6.1 of Connector/C currently receives only critical security bug fixes, but all bug fixes go to version 8.0 of Connector/C (which is the client library component of MySQL Server 8.0). See   https://dev.mysql.com/downloads/connector/c

Thanks,
Chiranjeevi.
[3 Jul 2018 14:47] Igor Korot
Hi,
[quote]
Hello Igor,

Thank you for your feedback.
Note that we do not actively support version 6.1 of Connector/C any more and this is why your report did not get as much attention as it should - sorry for that. But we are able to reproduce the same issue with the latest version of Connector/C (libmysqlclient).
[/quote]

Was it the case 6 month ago when I reported this?
Keep in mind though that not all *nix'es are doing an immediate update to their trees and even if this ticket will be fixed there is no guarantee it will be picked up by all *nix platforms.
I would be also curious to know whether it is a regression  or not and whether it ever worked as it should.

[quote]
Please be advised that version 6.1 of Connector/C currently receives only critical security bug fixes, but all bug fixes go to version 8.0 of Connector/C (which is the client library component of MySQL Server 8.0). See   https://dev.mysql.com/downloads/connector/c
[/quote]

So I presume that the fix for this ticket will be coming soon? And the fix will go to the latest version of Connector/C?
Now, there are 2 additional questions:
1. The latest version of Connector/C is backward compatible? Meaning that I can grab it and connect to the mySQL version 5?
2. What other versions this fix will go to? This is serious so hopefully it can be applied to the version I'm using as well.
[3 Jul 2018 15:10] Igor Korot
Hi,
I also want to get you attention to this:

1 https://packages.gentoo.org/packages/dev-db/mysql

This shows that the latest stable version for mySQL in Gentoo repository is 5.7.22.

2. https://packages.gentoo.org/packages/dev-db/mysql-connector-c

This shows that the latest stable version of Connector/C in Gentoo repository is 6.1.11 with some Gentoo-specific patches.

I have no idea when the latest version(s) will become stable for that OS and I can only work with what OS repository provides.

Now some other distro can have the latest versions of those 2 packages on the stable side and some may have an intermediate ones. I can only work with Gentoo right now (during development cycle).

Thank you. Hopefully the fix for this ticket can go to the 6.1 branch and all laser branches and then Gentoo can pick it up so I can update the package and continue with my development.
[4 Jul 2018 12:30] Rafal Somla
Posted by developer:
 
User has found this bug with Con/C 6.1.11 (most probably) run against MySQL Server 5.7. But our QA could reproduce it with libmysqlclient 8.0.11 also run against 5.7 server (using the same test case as user).

It is very unlikely we'll fix it in Con/C 6.1 which is not actively supported any more, but probably it should be fixed in libmysqlclient - thus changing category to CAPI.
[4 Jul 2018 12:39] Rafal Somla
Posted by developer:
 
Hi Igor,

I won't count on this issue being fixed in Con/C 6.1 - as said we do not maintain it any more and only fix critical security issues in this code base. However, it should be fixed in the MySQL client library, which is a good replacement for Con/C 6.1. The latest version of the client library is 8.0 but our sustaining team will determine if the fix needs to be fixed also in earlier versions like 5.7.

Regarding availability in Linux distros, you are right and we take this into account when deciding about back-porting bug fixes to previous GA versions. However, Con/C 6.1 is a special case as currently it is superseded by MySQL Client Library 5.7+. So your best bet would be to replace https://packages.gentoo.org/packages/dev-db/mysql-connector-c witch https://packages.gentoo.org/packages/dev-db/mysql (the libmysqlclient from there) and hopefully a fix for your bug will eventually land there.
[4 Jul 2018 15:40] Igor Korot
Hi, Rafal,
[quote]
Hi Igor,

I won't count on this issue being fixed in Con/C 6.1 - as said we do not maintain it any more and only fix critical security issues in this code base. However, it should be fixed in the MySQL client library, which is a good replacement for Con/C 6.1. The latest version of the client library is 8.0 but our sustaining team will determine if the fix needs to be fixed also in earlier versions like 5.7.

Regarding availability in Linux distros, you are right and we take this into account when deciding about back-porting bug fixes to previous GA versions. However, Con/C 6.1 is a special case as currently it is superseded by MySQL Client Library 5.7+. So your best bet would be to replace https://packages.gentoo.org/packages/dev-db/mysql-connector-c witch https://packages.gentoo.org/packages/dev-db/mysql (the libmysqlclient from there) and hopefully a fix for your bug will eventually land there.
[/quote]

I'm not sure what you are saying.
Are you saying that Connector/C is deprecated and people should start using some other library?
Or that the problem is not inside the Connector/C code but rather inside libmysqlclient and it should be fixed there?

Please clarify.

Also, it would be nice if you give me an estimate of when the bug will be fixed.

Thank you.
[9 Jul 2018 11:37] Rafal Somla
Posted by developer:
 
Hi Igor,

You should realize that 99% of Connector/C 6.1 code is actually the libmysqlclient code. So, most of the time the issues found when using Connector/C 6.1 are in fact issues in the libmysqlclient code, as is apparently the case with the issue you found. When Connector/C 6.1 was in active development the fixes in libmysqlclient code base were merged into Connector/C 6.1 code base too. But currently, Connnector/C 6.1 is not actively developed any more and thus it will not receive new bug fixes except for critical security ones.

At its time, Connector/C 6.1 provided some features that you could not find in libmysqlclient 5.6. But currently, libmysqlclient 5.7 and libmysqlclient 8.0 are more feature complete than Connector/C 6.1 and, as we discussed, receive new bug fixes. So yes, I think people should move away from Connector/C 6.1 and start using version 8.0 (i.e., the libmysqlclient of MySQL Server 8.0) to get the latest-and-greatest CAPI implementation or, if latest is not an option, then libmysqlclient 5.7 should be a better alternative than Connector/C 6.1. Depending on use case, one can also consider switching to our new API for plain C applications, X DevAPI for C, that is implemented by Connector/C++ 8.0 (see <https://dev.mysql.com/doc/connector-cpp/8.0/en/connector-cpp-introduction.html#connector-c...>).

About estimate, I can not give you one (it is not my decision). As with any other MySQL bug we'll evaluate it and then decide how and when to fix it.
[9 Jul 2018 15:11] Igor Korot
Hi,
[quote]
Hi Igor,

You should realize that 99% of Connector/C 6.1 code is actually the libmysqlclient code. So, most of the time the issues found when using Connector/C 6.1 are in fact issues in the libmysqlclient code, as is apparently the case with the issue you found. When Connector/C 6.1 was in active development the fixes in libmysqlclient code base were merged into Connector/C 6.1 code base too. But currently, Connnector/C 6.1 is not actively developed any more and thus it will not receive new bug fixes except for critical security ones.
[/quote]

It would be nice to have the fix included for Connector/C 6.1, but if not I will probably need to switch to the newer version  when the fix become available.

[quote]
At its time, Connector/C 6.1 provided some features that you could not find in libmysqlclient 5.6. But currently, libmysqlclient 5.7 and libmysqlclient 8.0 are more feature complete than Connector/C 6.1 and, as we discussed, receive new bug fixes. So yes, I think people should move away from Connector/C 6.1 and start using version 8.0 (i.e., the libmysqlclient of MySQL Server 8.0) to get the latest-and-greatest CAPI implementation or, if latest is not an option, then libmysqlclient 5.7 should be a better alternative than Connector/C 6.1. Depending on use case, one can also consider switching to our new API for plain C applications, X DevAPI for C, that is implemented by Connector/C++ 8.0 (see <https://dev.mysql.com/doc/connector-cpp/8.0/en/connector-cpp-introduction.html#connector-c...>).
[/quote]

No, I will just wait for this ticket to be fixed and the new release to be out. I hope that the ticket will be updated at that time and hopefully will reference the versions it will be applied and backported.

It would also be nice to know if this bug is a regression or it was always present - see my previous replies in this thread. Because if this is the regression - seeing what changes broke it will help fixing the ticket.

[/quote]
About estimate, I can not give you one (it is not my decision). As with any other MySQL bug we'll evaluate it and then decide how and when to fix it.
[/quote]

Yes, I understand. Thank you for trying to fix the problem and I'm glad I help make the mySQL products better.

Thank you.