[CONC-137] Error code not set in mysql_stmt_send_long_data Created: 2015-08-16  Updated: 2015-08-16  Resolved: 2015-08-16

Status: Closed
Project: MariaDB Connector/C
Component/s: None
Affects Version/s: 2.1
Fix Version/s: 3.0.0, 2.2.0

Type: Bug Priority: Minor
Reporter: Matt Fagan Assignee: Georg Richter
Resolution: Fixed Votes: 0
Labels: None
Environment:

All


 Description   

If you call mysql_stmt_send_long_data while the MYSQL* is in the wrong state, it returns the fact that there is an error, but no error code.
See line 1826 of my_stmt.c.

To correct, I think the conditional on line 1816 needs to be changed from:
if (stmt->mysql->status== MYSQL_STATUS_READY && (length || !stmt->params[param_number].long_data_used))
{

To:
if (stmt->mysql->status != MYSQL_STATUS_READY)
SET_CLIENT_STMT_ERROR(stmt, CR_COMMANDS_OUT_OF_SYNC, SQLSTATE_UNKNOWN, 0);
DBUG_RETURN(1);
}

if (length || !stmt->params[param_number].long_data_used))
{

 Comments   
Comment by Georg Richter [ 2015-08-16 ]

Hi Matt,

thanks for your bug report.

The extra check for status is redundant, since it will be checked in simple_command/mthd_my_send_cmd. To be compatible with libmysql we also should allow to pass a zero length buffer instead of returning an error.:

--- a/libmariadb/my_stmt.c
 
+++ b/libmariadb/my_stmt.c
 
@@ -1811,7 +1811,7 @@ my_bool STDCALL mysql_stmt_send_long_data(MYSQL_STMT *stmt, uint param_number,
 
     DBUG_RETURN(1);
 
   }
 
 
-  if (stmt->mysql->status== MYSQL_STATUS_READY && (length || !stmt->params[param_number].long_data_used))
 
+  if (length || !stmt->params[param_number].long_data_used)
 
   {
 
     int ret;
 
     size_t packet_len;
 
@@ -1824,7 +1824,7 @@ my_bool STDCALL mysql_stmt_send_long_data(MYSQL_STMT *stmt, uint param_number,
 
     my_free(cmd_buff);
 
     DBUG_RETURN(ret); 
   } 
-  DBUG_RETURN(1);
 
+  DBUG_RETURN(0);
 
 }
 
 
 my_ulonglong STDCALL mysql_stmt_insert_id(MYSQL_STMT *stmt)

Comment by Georg Richter [ 2015-08-16 ]

fixed (changeset a6f40f2b97b35a15b75c3a419fcfe3a894628675)

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