USER VARIABLE = CRASH
Moved the preparation of the variables that receive the output from
SELECT INTO from execution time (JOIN:execute) to compile time
(JOIN::prepare). This ensures that if the same variable is used in the
SELECT part of SELECT INTO it will be properly marked as non-const
for this query.
Test case added.
Used proper fast iterator.
assignments and comparison in query
A query that compares assignments of the same
user variable caused Valgrind warnings: access
to freed memory region.
In case of a DECIMAL argument the assignment
operator (:=) may return a pointer to a stored
value instead of its copy when evaluated.
The next assignment to the same variable may:
a) overwrite the stored value with a new one
and return the same pointer or even
b) reallocate stored value.
Thus, if we evaluate an assignment and keep
the result pointer and then evaluate another
assignment to the same variable, then the
kept result pointer of the first assignment
will point to unexpectedly changed data or
it may be a dead pointer.
That may cause wrong data or crash.
The user_var_entry::val_decimal method has
been modified to copy user variable data.
An user assignment variable expression that's
evaluated in a logical expression context
(Item::val_bool()) can be pre-calculated in a
temporary table for GROUP BY.
However when the expression value is used after the
temp table creation it was re-evaluated instead of
being read from the temp table due to a missing
val_bool_result() method.
Fixed by implementing the method.
The bug happened under the following condition:
- there was a user variable of type REAL, containing NULL value
- there was a table with a NOT_NULL column of any type but REAL, having
default value (or auto increment);
- a row was inserted into the table with the user variable as value.
A warning was emitted here.
The problem was that handling of NULL values of REAL type was not properly
implemented: it didn't expect that REAL NULL value can be assigned to other
data type.
Basically, the problem was that set_field_to_null() was used instead of
set_field_to_null_with_conversions().
The fix is to use the right function, or more generally, to allow conversion of
REAL NULL values to other data types.
Bug#16565 mysqld --help --verbose does not order variablesBug#20413 sql_slave_skip_counter is not shown in show variables
Bug#20415 Output of mysqld --help --verbose is incomplete
Bug#25430 variable not found in SELECT @@global.ft_max_word_len;
Bug#32902 plugin variables don't know their names
Bug#34599 MySQLD Option and Variable Reference need to be consistent in formatting!
Bug#34829 No default value for variable and setting default does not raise error
Bug#34834 ? Is accepted as a valid sql mode
Bug#34878 Few variables have default value according to documentation but error occurs
Bug#34883 ft_boolean_syntax cant be assigned from user variable to global var.
Bug#37187 `INFORMATION_SCHEMA`.`GLOBAL_VARIABLES`: inconsistent status
Bug#40988 log_output_basic.test succeeded though syntactically false.
Bug#41010 enum-style command-line options are not honoured (maria.maria-recover fails)
Bug#42103 Setting key_buffer_size to a negative value may lead to very large allocations
Bug#44691 Some plugins configured as MYSQL_PLUGIN_MANDATORY in can be disabled
Bug#44797 plugins w/o command-line options have no disabling option in --help
Bug#46314 string system variables don't support expressions
Bug#46470 sys_vars.max_binlog_cache_size_basic_32 is broken
Bug#46586 When using the plugin interface the type "set" for options caused a crash.
Bug#47212 Crash in DBUG_PRINT in mysqltest.cc when trying to print octal number
Bug#48758 mysqltest crashes on sys_vars.collation_server_basic in gcov builds
Bug#49417 some complaints about mysqld --help --verbose output
Bug#49540 DEFAULT value of binlog_format isn't the default value
Bug#49640 ambiguous option '--skip-skip-myisam' (double skip prefix)
Bug#49644 init_connect and \0
Bug#49645 init_slave and multi-byte characters
Bug#49646 mysql --show-warnings crashes when server dies
At the end of execution top level join execution
we cleanup this join with true argument.
It leads to underlying join cleanup(subquery) with true argument too
and to tmp_table_param->field array cleanup which is required later.
The problem is that Item_func_set_user_var does not set
result_filed which leads to unnecessary repeated excution of subquery
on final stage.
The fix is to set result_field for Item_func_set_user_var.
Problem: storing "SELECT ... INTO @var ..." results in variables we used val_xxx()
methods which returned results of the current row.
So, in some cases (e.g. SELECT DISTINCT, GROUP BY or HAVING) we got data
from the first row of a new group (where we evaluate a clause) instead of
data from the last row of the previous group.
Fix: use val_xxx_result() counterparts to get proper results.
in trigger
Interchangeable calls to the mysql_change_user client function
and invocations of a trigger changing some user variable caused
a memory corruption and a crash.
The mysql_change_user API call forces TDH::cleanup() on a server
that frees user variable entries.
However it didn't reset Item_func_set_user_var::entry to NULL
because Item_func_set_user_var::cleanup() was not overloaded.
So, Item_func_set_user_var::entry held a pointer to freed memory,
that caused a crash.
The Item_func_set_user_var::cleanup method has been overloaded
to cleanup the Item_func_set_user_var::entry field.
columns data types
The "SELECT @lastId, @lastId := Id FROM t" query returns
different result sets depending on the type of the Id column
(INT or BIGINT).
Note: this fix doesn't cover the case when a select query
references an user variable and stored function that
updates a value of that variable, in this case a result
is indeterminate.
The server uses incorrect assumption about a constantness of
an user variable value as a select list item:
The server caches a last query number where that variable
was changed and compares this number with a current query
number. If these numbers are different, the server guesses,
that the variable is not updating in the current query, so
a respective select list item is a constant. However, in some
common cases the server updates cached query number too late.
The server has been modified to memorize user variable
assignments during the parse phase to take them into account
on the next (query preparation) phase independently of the
order of user variable references/assignments in a select
item list.
The Item_func_set_user_var::register_field_in_read_map() did not check
that the result_field was null.This caused server crashes for queries that
required order by such a field and were executed without using a temporary
table.
The Item_func_set_user_var::register_field_in_read_map() now checks the
result_field to be not null.
Problem: there's no guarantee that the user variable item's result_field
is assigned when we're adjusting its table read map.
Fix: check the result_field before using it.
This is an additional fix.
Item::val_xxx methods are supposed to use original data source and
Item::val_xxx_result methods to use the item's result field. But for the
Item_func_set_user_var class val_xxx_result methods were mapped to val_xxx
methods. This leads, in particular, to producing bad sort keys and thus
wrong order of the result set of queries with group by/order by clauses.
The set of val_xxx_result methods is added to the Item_func_set_user_var
class. It's the same as the val_xxx set of method but uses the result_field
to return a value.
The end_update() function uses the Item::save_org_in_field() function to
save original values of items into the group buffer. But for the
Item_func_set_user_var this method was mapped to the save_in_field method.
The latter function wrongly decides to use the result_field. This leads to
saving incorrect value in the grouping buffer and wrong result of the whole
query.
The can_use_result_field argument of the bool type is added to the
Item_func_set_user_var::save_in_field() function. If it is set to FALSE
then the item's result field won't be used. Otherwise it will be detected
whether the result field will be used (old behaviour).
Two wrapping functions for the function above are added to the
Item_func_set_user_var class:
the save_in_field(Field *field, bool no_conversions) - it calls the above
function with the can_use_result_field set to TRUE.
the save_org_in_field(Field *field) - same, but the can_use_result_field
is set to FALSE.
used.
The Item::save_in_field() function is called from fill_record() to fill the
new row with data while execution of the CREATE TABLE ... SELECT statement.
Item::save_in_field() calls val_xxx() methods in order to get values.
val_xxx() methods do not take into account the result field. Due to this
Item_func_set_user_var::val_xxx() methods returns values from the original
table, not from the temporary one.
The save_in_field() member function is added to the Item_func_set_user_var
class. It detects whether the result field should be used and properly updates
the value of the user variable.
- Honor unsigned_flag in the corresponding functions
- Use compare_int_signed_unsigned()/compare_int_unsigned_signed() instead of explicit comparison in GREATEST() and LEAST()
used.
Sorting by RAND() uses a temporary table in order to get a correct results.
User defined variable was set during filling the temporary table and later
on it is substituted for its value from the temporary table. Due to this
it contains the last value stored in the temporary table.
Now if the result_field is set for the Item_func_set_user_var object it
updates variable from the result_field value when being sent to a client.
The Item_func_set_user_var::check() now accepts a use_result_field
parameter. Depending on its value the result_field or the args[0] is used
to get current value.
Gluh's SESSION/GLOBAL for @variables fix in sql_yacc.yy and
Bar's well_formed_len() changes in ndb code
did not make it and should be re-applied manually
