MySQL Bugs: #61225: Incorrect arguments to mysqld_stmt

Bug #61225	Incorrect arguments to mysqld_stmt_execute code: 1210 state: HY000
Submitted:	19 May 2011 10:55	Modified:	24 May 2011 16:20
Reporter:	Grzegorz B	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server	Severity:	S2 (Serious)
Version:	5.1.49	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	Contribution

Description:
Hello.

I'm experiencing problems with MySQL after ugrade from 5.0 to 5.1 (Debian Squeeze).

Before, I was using PreparedStatements with C++ Connector (version 1.1.0~r814-1), and after MySQL Server upgrade, PreparedStatements are working *strange*.

Error: Incorrect arguments to mysqld_stmt_execute code: 1210 state: HY000

The most strange thing about this is the fact that this error occurs only when general_log GLOBAL variable is set to OFF. When general_log is ON - everything works fine (strange, isn't it ?) and I'm unable to log what is really happening.

I was unable to track this further, as digging inside MySql code is quite a challenge. 

I hope someone will be able to investigate this more thoroughly.

Regards,
 Grzegorz B.
 ntsn.pl software development
 http://ntsn.pl/en

How to repeat:

Application code (small part):

istatement = sqlConnection->prepareStatement("INSERT INTO tab1 (iId, iDateTime, binData) VALUES(?, ?, ?)");

istatement->setInt(1, id);
istatement->setInt64(2, ttime);
istatement->setBlob(3, &istream);

istatement->execute();

Please, check if the same problem happens with a recent version, 5.1.57.

I will try it on 5.1.57 as soon as possible.

So far I tracked it to relation with using setBlob() and corresponding LONG_DATA.

Changing BLOB to INT did the trick - but it is unacceptable workaround for me.

I suppose it is possible that this bug is related to this one:

http://bugs.mysql.com/bug.php?id=26824 - active since 2007 as someone tagged it as "to be fixed later".

Interesting thing is that it worked for me on 5.1.49, and why general_log is affecting behaviour of mysql-server ?

Regards,
 Grzegorz
 http://ntsn.pl

Hello again.

I've checked this using code from 5.1.57 and it appears that this has been fixed in that version (file sql/sql_prepare.cc).

I merged files sql_prepare.cc from 5.1.49 and 5.1.57 (working version) and produced patch that fixes this bug in 5.1.49 (I'm using debian package, and I don't want to upgrade to 5.1.57 from unstable on production server):

--- mysql-5.1-5.1.49_old/sql/sql_prepare.cc     2011-05-23 10:27:56.000000000 +0200
+++ mysql-5.1-5.1.49/sql/sql_prepare.cc 2011-05-23 12:08:27.000000000 +0200
@@ -264,7 +264,9 @@
                                           Protocol::SEND_EOF);
   }
   /* Flag that a response has already been sent */
-  thd->main_da.disable_status();
+  if (!error)
+    thd->main_da.disable_status();
+
   DBUG_RETURN(error);
 }
 #else
@@ -836,7 +838,7 @@
       type (the types are supplied at execute). Check that the
       supplied type of placeholder can accept a data stream.
     */
-    else if (is_param_long_data_type(param))
+    else if (! is_param_long_data_type(param))
       DBUG_RETURN(1);
     if (param->convert_str_value(stmt->thd))
       DBUG_RETURN(1);                           /* out of memory */
@@ -2358,12 +2360,14 @@
       {
         sl->where= sl->prep_where->copy_andor_structure(thd);
         sl->where->cleanup();
-      }
+      } else
+        sl->where= NULL;
       if (sl->prep_having)
       {
         sl->having= sl->prep_having->copy_andor_structure(thd);
         sl->having->cleanup();
-      }
+      } else
+        sl->having= NULL;
       DBUG_ASSERT(sl->join == 0);
       ORDER *order;
       /* Fix GROUP list */
@@ -3265,6 +3269,13 @@
   if (set_parameters(expanded_query, packet, packet_end))
     return TRUE;

+  /* Check if we got an error when sending long data */
+  if (state == Query_arena::ERROR)
+  {
+    my_message(last_errno, last_error, MYF(0));
+    return TRUE;
+  }
+
 reexecute:
   reprepare_observer.reset_reprepare_observer();

@@ -3502,12 +3513,6 @@

   status_var_increment(thd->status_var.com_stmt_execute);

-  /* Check if we got an error when sending long data */
-  if (state == Query_arena::ERROR)
-  {
-    my_message(last_errno, last_error, MYF(0));
-    return TRUE;
-  }
   if (flags & (uint) IS_IN_USE)
   {
     my_error(ER_PS_NO_RECURSION, MYF(0));
                                             
Applying this patch on 5.1.49 allows me to use setBlob in C++ Connector, and everything appears to work fine (I hope), but I'm not completely sure what change in this patch fixed this problem.

I think that this bug can be closed now, but I also think that someone should take a look at this patch, and clarify what was wrong (so other people could use this on 5.1.49 safely).

Anyway - thanks for fixing this issue !

Regards,
 Grzegorz Bizon
 ntsn.pl software development
 http://ntsn.pl

MySQL prepared statement longdata issue patch for 5.1.49

Attachment: mysql_pstmt_longdata.patch (text/x-diff), 1.88 KiB.

Thank you for the patch. It may be useful for other community members.

I am closing this report as not repeatable on current version, 5.1.57.