Open btGuo opened 4 months ago
Hi @btGuo . Thank you for the report. Unless you provide a reproducible test case and/or a core dump, there is little I can suggest right now other than upgrading to the latest version. Are you able to provide a core dump?
Please note that setting fast_forward=1
disables the vast majority of the features of proxysql.
Hi @btGuo . Thank you for the report. Unless you provide a reproducible test case and/or a core dump, there is little I can suggest right now other than upgrading to the latest version. Are you able to provide a core dump?
Please note that setting
fast_forward=1
disables the vast majority of the features of proxysql.
Thanks for your reply, unfortunately the core dump file was lost. If I get a core file next time, I will try provide it. I have read the bug fix between 2.5.1 and the newest version, but I can't find something related to this problem. These days I reading the source code and I found that mysql_decode_length was called in case MYSQL_TYPE_GEOMETRY, but our program never use this mysql data type, I think that there maybe some dirty memory. I understand that enable fast_forward will lost many features (such as stats_mysql_query_digests metrics we currently used).
Hi @btGuo .
Yes please, if you try to reproduce it, please let us know.
Please note that mysql_decode_length is used for many data type, specifically any data type that do not have a fixed length.
Hi @btGuo .
Yes please, if you try to reproduce it, please let us know.
Please note that mysql_decode_length is used for many data type, specifically any data type that do not have a fixed length.
Oh, I got it, there are multi 'case'.
OS version: Debian 10; kernel: 4.19.117.bsk.business.1-amd64
ProxySQL version: 2.5.1-90-gbedaa6c
Mysql version: 5.7.37
Mysql client sdk: go-sql-driver/mysql
logs:
proxysql crashed when processing stmt_execute packet; this problem happens twice in our production environment; finally I set fast_forward=1 and this problem did not occur again.