Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.2.4
-
Linux Debian 8.6 / 64bits, Windows 10 / 64bits
-
10.2.6-2, 10.2.6-3
Description
Same code working with 10.1 now hangs when executing a simple SELECT ...
So far could only enable server log to see what happens.
Must investigate to enable more detailed log or debug info... any suggestion is welcome.
Tcp port: 3309 Unix socket: /opt3/dbs/mdb/10.2/data/mysqld.sock
|
Time Id Command Argument
|
170313 18:36:53 7 Connect mysuser@localhost as anonymous on test1
|
7 Query SELECT @@version
|
7 Query SET autocommit=1
|
7 Prepare delete from dbit2
|
7 Execute delete from dbit2
|
7 Close stmt
|
7 Prepare insert into dbit2 VALUES (1,'aaa','bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb')
|
7 Execute insert into dbit2 VALUES (1,'aaa','bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb')
|
7 Close stmt
|
7 Prepare insert into dbit2 VALUES (2,'bbb','bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb')
|
7 Execute insert into dbit2 VALUES (2,'bbb','bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb')
|
7 Close stmt
|
7 Prepare insert into dbit2 VALUES (3,'ccc','bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb')
|
7 Execute insert into dbit2 VALUES (3,'ccc','bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb')
|
7 Prepare select dbit2_key from dbit2 where dbit2_key<?
|
7 Prepare select dbit2_key from dbit2 where dbit2_key<?
|
7 Execute select dbit2_key from dbit2 where dbit2_key<-1
|
Have stopped and restarted the server several times, only one single client connects.... strange.
Attachments
Issue Links
- relates to
-
-
- Open
-
Activity
I could reproduce with a simplified program: Try attachment MDEV-12247.c
Seems to be related to the cursor type setting with mysql_stmt_attr_set()...
- With default MYSQL_STMT settings = no issue
- When setting STMT_ATTR_CURSOR_TYPE to CURSOR_TYPE_READ_ONLY, server does not respond on second execute...
Please try to reproduce on your side and let me know.
Here is the output I get when it hangs:
mysql_real_connect() ...
|
mysql_stmt_init() ...
|
mysql_stmt_prepare() ...
|
mysql_stmt_attr_set( ... STMT_ATTR_CURSOR_TYPE ... ) ...
|
mysql_stmt_execute()...
|
Re- mysql_stmt_execute()...
|
... must interrupt with CTRL-C / SIGINT ...
|
Thanks a lot, reproducible for me with the libraries from 10.2.4 and mariadb-connector 3.0.1 (and not reproducible with libraries from 10.1).
wlad will be further looking into it.
Fix pushed to Connector/C master branch
commit 63e0897d43881b6fcdcc4eff1d38b8e201dce631
Author: Georg Richter <georg@mariadb.com>
Date: Tue Mar 21 17:26:19 2017 +0100
Double prepare:
To make it short, our programming language Genero BDL has 2 instructions to prepare and then declare a cursor:
PREPARE s153 FROM "SELECT dbit2_key FROM dbit2 WHERE dbit2_key<?" -- ends up as Prepare 1DECLARE c153 CURSOR FOR s153 -- ends up as Prepare 2LET n = -1OPEN c153 USING n -- ends up as ExecuteIn fact, the Genero BDL code does an OPEN USING followed by FOREACH loop. This ends up in a first call to mysql_stmt_bind_param() + mysql_stmt_execute(), and then the FOREACH makes again a call to mysql_stmt_execute()...
(I must admit this is very particular but legal code, that we have to support)
LET n = -1OPEN c153 USING n -- ends up as a mysql_stmt_bind_param() + mysql_stmt_execute()FOREACH c153 -- ends up as a second mysql_stmt_execute()I suspect however that MariaDB does not deal properly with these subsequent executes, or that we misuse the MariaDB client API in this case... (but our C code implementing these instructions exists for a while and is working fine with MySQL 5.7 client and MariaDB 10.1)
I will try to provide a pure MySQL C sample that reproduces the problem.