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: | |
| 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
[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.