The server crashed when a thread was killed while locking the
general_log table at statement begin.
The general_log table is handled like a performance schema table.
The state of open tables is saved and cleared so that this table
seems to be the only open one. Then this table is opened and locked.
After writing, the table is closed and the open table state is
restored. Before restoring, however, it is asserted that there is
no current table open.
After locking the table, mysql_lock_tables() checks if the thread
was killed in between. If so, it unlocks the table and returns an
error. open_ltable() just returns with the error and leaves closing
of the table to close_thread_tables(), which is called at
statement end.
open_performance_schema_table() did not take this into account.
It assumed that a failed open_ltable() would not leave an open
table behind.
Fixed by closing thread tables after open_ltable() and before
restore_backup_open_tables_state() if the thread was killed.
No test case. It requires correctly timed parallel execution.
Since this bug was detected by the test suite, it seems
dispensable to add another test.
No warning was generated when a TIMESTAMP with a non-zero time part
was converted to a DATE value. This caused index lookup to assume
that this is a valid conversion and was returning rows that match
a comparison between a TIMESTAMP value and a DATE keypart.
Fixed by generating a warning on such a truncation.
Buffer used when setting variables was not dimensioned to accomodate
trailing '\0'. An overflow by one character was therefore possible.
CS corrects limits to prevent such overflows.
Previously, UDF *_init functions were passed constant strings with erroneous lengths. The length came from the containing variable's size, not the length of the value itself.
Now the *_init functions get the constant as a null terminated string with the correct length supplied too.
table to partitioned
Problem:
Crashed because usage of an uninitialised mutex when auto_incrementing
a partitioned temporary table
Fix:
Only locking (using the mutex) if not temporary table.
CPUs / Intel's ICC compile
The bug is a combination of two problems:
1. IA64/ICC MySQL binaries use glibc's qsort(), not the one in mysys.
2. The order relation implemented by join_tab_cmp() is not transitive,
i.e. it is possible to choose such a, b and c that (a < b) && (b < c)
but (c < a). This implies that result of a sort using the relation
implemented by join_tab_cmp() depends on the order in which
elements are compared, i.e. the result is implementation-specific. Since
choose_plan() uses qsort() to pre-sort the
join tables using join_tab_cmp() as a compare function, the results of
the sorting may vary depending on qsort() implementation.
It is neither possible nor important to implement a better ordering
algorithm in join_tab_cmp(). Therefore the only way to fix it is to
force our own qsort() to be used by renaming it to my_qsort(), so we don't depend
on linker to decide that.
This patch also "fixes" bug #20530: qsort redefinition violates the
standard.
The problem was that the RETURNS column in the mysql.proc was of
CHAR(64). That was not enough for storing long-named datatypes.
The fix is to change CHAR(64) to LONGBLOB, and to throw warnings
at the time a stored routine is created if some data is truncated
during writing into mysql.proc.
storage engines do not set the unused null bits (i.e., the
filler bits and the X bit) correctly. Also adding some casts
to debug printouts to eliminate compiler warnings.
The embedded version of the server doesn't use column level grants, and
the compile directive NO_EMBEDDED_ACCESS_CHECKS should be checked instead of
the redundant HAVE_QUERY_CACHE (which is always the case) to determine if
column level grants should be compiled or not.
Problem: we don't evaluate given expression checking values of the
slow_query_log_file/general_log_file, don't check it for NULL.
Fix: evaluate the expression, check result returned.
The root cause of the issue was that the CREATE FUNCTION grammar,
for User Defined Functions, was using the sp_name rule.
The sp_name rule is intended for fully qualified stored procedure names,
like either ident.ident, or just ident but with a default database
implicitly selected.
A UDF does not have a fully qualified name, only a name (ident), and should
not use the sp_name grammar fragment during parsing.
The fix is to re-organize the CREATE FUNCTION grammar, to better separate:
- creating UDF (no definer, can have AGGREGATE, simple ident)
- creating Stored Functions (definer, no AGGREGATE, fully qualified name)
With the test case provided, another issue was exposed which is also fixed:
the DROP FUNCTION statement was using sp_name and also failing when no database
is implicitly selected, when droping UDF functions.
The fix is also to change the grammar so that DROP FUNCTION works with
both the ident.ident syntax (to drop a stored function), or just the ident
syntax (to drop either a UDF or a Stored Function, in the current database)
if remote server sends malicious response.
We need to check if the SHOW TABLE STATUS query we issue inside the
FEDERATED engine returned the result with the proper (or just sufficient)
number of rows. Otherwise statements like row[12] can crash the server.
