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

[19 May 2011 10:55] Grzegorz B
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();
[19 May 2011 12:21] Valeriy Kravchuk
Please, check if the same problem happens with a recent version, 5.1.57.
[19 May 2011 13:16] Grzegorz B
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
[23 May 2011 11:52] Grzegorz B
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
[23 May 2011 11:53] Grzegorz B
MySQL prepared statement longdata issue patch for 5.1.49

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

[24 May 2011 16:20] Valeriy Kravchuk
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.

Portions of this website are copyright © 2001, 2002 The PHP Group

Page generated in 0.055 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.