diff options
author | Neeraj Bisht <neeraj.x.bisht@oracle.com> | 2013-08-28 14:54:53 +0530 |
---|---|---|
committer | Neeraj Bisht <neeraj.x.bisht@oracle.com> | 2013-08-28 14:54:53 +0530 |
commit | d4b4c8274b43c618523fe2550a433a359b0c3ee7 (patch) | |
tree | 1eb5e8a4bcf5dc37fe90c6ccb1a3e2e7ba46368d /vio | |
parent | 48d942e273cfa6577cdeb23b68499d15e71bea05 (diff) | |
download | mariadb-git-d4b4c8274b43c618523fe2550a433a359b0c3ee7.tar.gz |
Bug#16346241 - SERVER CRASH IN ITEM_PARAM::QUERY_VAL_STR
Problem:-
Second execution of prepared statement for query with
parameter in limit clause, causes an assert when using
connectors (e.g., Connector C).
Analysis:-
In prepared statement, LIMIT parameters can be
specified using '?' markers. Value for the parameter can
be supplied while executing the prepared statement.
Passing string, float or double values for LIMIT clause
works well from command-line client. That's because, while
setting the LIMIT parameter value from a user-variable,
the value is converted to integer value.
However, when prepared statement is executed from other
interfaces as J connectors, or C applications etc,
the value for the parameters are sent to the server
with execute command. Each item in command has value and
the data TYPE. So, while setting parameter values
from this log, value is set to all the parameters
with the same data type as passed.
Here, we have the logic to convert the value to change the
state and item_type if it is part of LIMIT parameter and
its item_type is not INT.
But when we reset this parameter we save the item_type but change
state. So on second execution we have old item_type but our state
has been changed, which make us to use string type variable
in Item_param::query_str_val(). This cause an assert.
Fix:
Instead of checking the item_type of the parameter, check for
the state of the parameter. As state value are reset everytime
we execute the statement.
Diffstat (limited to 'vio')
0 files changed, 0 insertions, 0 deletions