[CONC-435] Connector stmt sends 'close' command if stmt handle was never used Created: 2019-08-19  Updated: 2021-01-20

Status: Open
Project: MariaDB Connector/C
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Lawrin Novitsky Assignee: Lawrin Novitsky
Resolution: Unresolved Votes: 1
Labels: None


 Description   

If application inits stmt handle, but then closes it without use, C/C sends redundant 'close' command to the server for the stmtid==0. Application has to call mysql_stmt_close in this case, as it needs to free allocated stmt handle memory, anyway.
I am not sure if this is a bug or an improvement. But this scenario happens in C/ODBC quite often, as it allocates stmt along with ODBC statement handle allocation, and I'd prefer not to fix this in GA version.

 Comments   
Comment by George Diamantopoulos [ 2019-09-02 ]

Hello all,

If there's a patch available or a fix lands in master for this issue, please let me know via this issue. I can test against an application that is known to trigger this. Thanks!

Comment by Georg Richter [ 2019-09-03 ]

Can you provide a test case please to reproduce this issue?
Usually client should only send COM_STMT_CLOSE if stmt->status > MYSQL_STMT_INITED.

Comment by George Diamantopoulos [ 2019-09-05 ]

@georg

Actually I didn't come across this during development using C/C. It manifests when using asterisk 16 with an ODBC backend via C/ODBC. If you believe this to be a client issue, I can raise this with asterisk devs, but it was Lawrin who suggested that this be dealt with in either C/C or C/ODBC in MXS-2490.

Having said that, asterisk functionality doesn't seem to be affected, as far as I can tell. The main issue is that Maxscale's log, which sits between C/ODBC and the MariaDB servers, is inundated with warnings about this.

In terms of further debugging information, what I can provide is an ODBC trace with the client's (asterisk's) behaviour. If that would be of any value, please let me know. Thanks!

Comment by Lawrin Novitsky [ 2019-09-10 ]

Well, that looked for me as most viable version explaining those 0 stmt id's. I'll try to repeat that with C/ODBC
Possibly this is something, that MaxScale does

Comment by Serge Rogatch [ 2020-06-08 ]

I'm getting "Unknown prepared statement handler (300) given to mysqld_stmt_execute". Is it the same bug, or shall I open a new ticket? Can someone explain what 300 stands for?

Comment by Georg Richter [ 2020-06-08 ]

I wonder if we had some similiar bug already in ODBC.

This is the relevant part in Connector/C:

if (stmt->state > MYSQL_STMT_INITTED)
 
    {
 
      int4store(stmt_id, stmt->stmt_id);
 
      if (stmt->mysql->methods->db_command(stmt->mysql,COM_STMT_CLOSE, stmt_id,
 
                                           sizeof(stmt_id), 1, stmt))
 
      {
 
        UPDATE_STMT_ERROR(stmt);
 
        return 1;
 
      }
 
    }

That means, we will only send a COM_STMT_CLOSE if the statement was already prepared. Is there any chance to debug and to check if stmt->id has a value? Also a valgrind run would be useful, to check if something was overwritten.

Comment by Georg Richter [ 2021-01-20 ]

Can you check if this issue was also fixed by fix for CONC-522 ?

Generated at Thu Feb 08 03:05:18 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.