There are two problems with ANALYSE():
1. Memory leak
it happens because do_select() can overwrite
JOIN::procedure field(with zero value in our case) and
JOIN destructor don't free the memory allocated for
JOIN::procedure. The fix is to save original JOIN::procedure
before do_select() call and restore it after do_select
execution.
2. Wrong result
If ANALYSE() procedure is used for the statement with LIMIT clause
it could retrun empty result set. It happens because of missing
analyse::end_of_records() call. First end_send() function call
returns NESTED_LOOP_QUERY_LIMIT and second call of end_send() with
end_of_records flag enabled does not happen. The fix is to return
NESTED_LOOP_OK from end_send() if procedure is active.
When we create temporary result table for UNION
incorrect max_length for YEAR field is used and
it leads to incorrect field value and incorrect
result string length as YEAR field value calculation
depends on field length.
The fix is to use underlying item max_length for
Item_sum_hybrid::max_length intialization.
Valgrind warning happens due to early null values check
in Item_func_in::fix_length_and_dec(before item evaluation).
As result null value items with uninitialized values are
placed into array and it leads to valgrind warnings during
value array sorting.
The fix is to check null value after item evaluation, item
is evaluated in in_array::set() method.
Select from a view with the underlying HAVING clause failed with a
message: "1356: View '...' references invalid table(s) or column(s)
or function(s) or definer/invoker of view lack rights to use them"
The bug is a regression of the fix for bug 11750328 - 40825 (similar
case, but the HAVING cause references an aliased field).
In the old fix for bug 40825 the Item_field::name_length value has
been used in place of the real length of Item_field::name. However,
in some cases Item_field::name_length is not in sync with the
actual name length (TODO: combine name and name_length into a
solid String field).
The Item_ref::print() method has been modified to calculate actual
name length every time.
create_schema if auto-generate-sql also set.
mysqlslap uses a schema to run its tests on and later
drops it if auto-generate-sql is used. This can be a
problem, if the schema is an already existing one.
If create-schema is used with auto-generate-sql option,
mysqlslap while performing the cleanup, drops the specified
database.
Fixed by introducing an option --no-drop, which, if used,
will prevent the dropping of schema at the end of the test.
on lctn2 systems
There was a local variable in get_all_tables() to store the
"original" value of the database name as it can get lowercased
depending on the lower_case_table_name value.
get_all_tables() iterates over database names and for each
database iterates over the tables in it.
The "original" db name was assigned in the table names loop.
Thus the first table is ok, but the second and subsequent tables
get the lowercased name from processing the first table.
Fixed by moving the assignment of the original database name
from the inner (table name) to the outer (database name) loop.
Test suite added.
In the string context the MIN() and MAX() functions don't take
into account the unsignedness of the UNSIGNED BIGINT argument
column.
I.e.:
CREATE TABLE t1 (a BIGINT UNSIGNED);
INSERT INTO t1 VALUES (18446668621106209655);
SELECT CONCAT(MAX(a)) FROM t1;
returns -75452603341961.
Valgrind warning happens because null values check happens too late
in Item_func_month::val_str(after result string calculation).The fix
is to check null value before result string calculation.
ASSERTION TABLE->DB_STAT FAILED IN
SQL_BASE.CC::OPEN_TABLE() DURING I_S Q
This assert could be triggered if a statement requiring a name
lock on a table (e.g. DROP TRIGGER) executed concurrently
with an I_S query which also used the table.
One connection first started an I_S query that opened a given table.
Then another connection started a statement requiring a name lock
on the same table. This statement was blocked since the table was
in use by the I_S query. When the I_S query resumed and tried to
open the table again as part of get_all_tables(), it would encounter
a table instance with an old version number representing the pending
name lock. Since I_S queries ignore version checks and thus pending
name locks, it would try to continue. This caused it to encounter
the assert. The assert checked that the TABLE instance found with a
different version, was a real, open table. However, since this TABLE
instance instead represented a pending name lock, the check would
fail and trigger the assert.
This patch fixes the problem by removing the assert. It is ok for
TABLE::db_stat to be 0 in this case since the TABLE instance can
represent a pending name lock.
Test case added to lock_sync.test.
Valgrind warning happens due to uninitialized cached_format_type field
which is used later in Item_func_str_to_date::val_str method.
The fix is to init cached_format_type field.
Assert fails due to overflow which happens in
Item_func_int_val::fix_num_length_and_dec() as
geometry functions have max_length value equal to
max_field_size(4294967295U). The fix is to skip
max_length calculation for some boundary cases.
Assertion happens due to missing initialization of unsigned_flag
for Item_func_set_user_var object. It leads to incorrect
calculation of decimal field size.
The fix is to add initialization of unsigned_flag.
Problem: mysqlbinlog --server-id may filter out Format_description_log_events.
If mysqlbinlog does not process the Format_description_log_event,
then mysqlbinlog cannot read the rest of the binary log correctly.
This can have the effect that mysqlbinlog crashes, generates an error,
or generates output that causes mysqld to crash, generate an error,
or corrupt data.
Fix: Never filter out Format_description_log_events. Also, never filter
out Rotate_log_events.
ARE NOT BEING HONORED
max_allowed_packet works in conjunction with net_buffer_length.
max_allowed_packet is an upper bound of net_buffer_length.
So it doesn't make sense to set the upper limit lower than the value.
Added a warning (using ER_UNKNOWN_ERRROR and a specific message)
when this is done (in the log at startup and when setting either
max_allowed_packet or the net_buffer_length variables)
Added a test case.
Fixed several tests that broke the above rule.
Issue:
------
Due to prefix match, database like 'k' was matching with 'ka' and events of 'ka' we getting displayed for 'show event' of 'k'.
Resolution:
-----------
Scan for listing of events in a schema is made to be done on exact match of database (schema) name instead of just prefix.
The problem was that server didn't check resulting size of prepared
statement argument which was set using mysql_send_long_data() API.
By calling mysql_send_long_data() several times it was possible
to create overly big string and thus force server to allocate
memory for it. There was no way to limit this allocation.
The solution is to add check for size of result string against
value of max_long_data_size start-up parameter. When intermediate
string exceeds max_long_data_size value an appropriate error message
is emitted.
We can't use existing max_allowed_packet parameter for this purpose
since its value is limited by 1GB and therefore using it as a limit
for data set through mysql_send_long_data() API would have been an
incompatible change. Newly introduced max_long_data_size parameter
gets value from max_allowed_packet parameter unless its value is
specified explicitly. This new parameter is marked as deprecated
and will be eventually replaced by max_allowed_packet parameter.
Value of max_long_data_size parameter can be set only at server
startup.
Issue:
SSL_CIPHER set to a specific CIPHER name was not getting picked up by SHOW STATUS Command.
Solution:
If specific cipher name is specified, avoid overwriting of Cipher List with default Cipher names.
Part 2. Function QUOTE() was not multi-byte safe.
@ mysql-test/r/ctype_ucs.result
@ mysql-test/t/ctype_ucs.test
Adding tests
@ sql/item_strfunc.cc
Fixing Item_func_quote::val_str to be multi-byte safe.
@ sql/item_strfunc.h
Multiple size needed for quote characters to mbmaxlen
Problem: wrong character set pointer was passed to my_strtoll10_mb2,
which led to DBUG_ASSERT failure in some cases.
@ mysql-test/r/func_encrypt_ucs2.result
@ mysql-test/t/func_encrypt_ucs2.test
@ mysql-test/r/ctype_ucs.result
@ mysql-test/t/ctype_ucs.test
Adding tests
@ sql/item_func.cc
"cs" initialization was wrong (res does not necessarily point to &str_value)
@ sql/item_strfunc.cc
Item_func_dec_encrypt::val_str() and Item_func_des_descrypt::val_str()
did not set character set for tmp_value (the returned value),
so the old value, which was previously copied from args[1]->val_str(),
was incorrectly returned with tmp_value.
Problem: a byte behind the end of input string was read
in case of a broken XML not having a quote or doublequote
character closing a string value.
Fix: changing condition not to read behind the end of input string
@ mysql-test/r/xml.result
@ mysql-test/t/xml.test
Adding tests
@ strings/xml.c
When checking if the closing quote/doublequote was found,
using p->cur[0] us unsafe, as p->cur can point to the byte after the value.
Comparing p->cur to p->beg instead.
("-") IN DATABASE NAMES IN ALTER DATABASE.
mysqldump did not quote database name in 'ALTER DATABASE'
statements in its output. This can further cause a failure
while loading if database name contains a hyphen '-'.
This happened as, while printing the 'ALTER DATABASE'
statements, the database name was not quoted.
Fixed by quoting the database name.
The loop that was looping over subqueries' references to outer field used a
local boolean variable to tell whether the field was grouped or not. But the
implementor failed to reset the variable after each iteration. Thus a field
that was not directly aggregated appeared to be.
Fixed by resetting the variable upon each new iteration.
memory reference
There are two issues present here.
1) There is a possibility that we test a byte beyond the
allocated buffer
2) We compare a byte that might never have been
initalized to see if it's 0.
The first issue is not triggered by existing code, but an
ASSERT has been added to safe-guard against introducing
new code that triggers it.
The second issue is what triggers the Valgrind warnings
reported in the bug report. A buffer is allocated in
class String to hold the value. This buffer is populated
by the character data constituting the string, but is not
zero-terminated in most cases. Testing if it is indeed
zero-terminated means that we check a byte that has never
been explicitly set, thus causing Valgrind to trigger.
Note that issue 2 is not a serious problem. The variable
is read, and if it's not zero, we will set it to zero.
There are no further consequences.
Note that this patch does not fix the underlying problems
with issue 1, as it is deemed too risky to fix at this
point (as noted in the bug report). As discussed in
the report, the c_ptr() method should probably be
replaced, but this requires a thorough analysis of the
~200 calls to the method.
attempt to create spatial index on char > 31 bytes".
Attempt to create spatial index on char field with length
greater than 31 byte led to assertion failure on server
compiled with safemutex support.
The problem occurred in mi_create() function which was called
to create a new version of table being altered. This function
failed since it detected an attempt to create a spatial key
on non-binary column and tried to return an error.
On its error path it tried to unlock THR_LOCK_myisam mutex
which has not been not locked at this point. Indeed such an
incorrect behavior was caught by safemutex wrapper and caused
assertion failure.
This patch fixes the problem by ensuring that mi_create()
doesn't releases THR_LOCK_myisam mutex on error path if it was
not acquired.
privileges".
The first problem was that DROP USER didn't properly remove privileges
on stored functions from in-memory structures. So the dropped user
could have called stored functions on which he had privileges before
being dropped while his connection was still around.
Even worse if a new user with the same name was created he would
inherit privileges on stored functions from the dropped user.
Similar thing happened with old user name and function privileges
during RENAME USER.
This problem stemmed from the fact that the handle_grant_data() function
which handled DROP/RENAME USER didn't take any measures to update
in-memory hash with information about function privileges after
updating them on disk.
This patch solves this problem by adding code doing just that.
The second problem was that RENAME USER didn't properly update in-memory
structures describing table-level privileges and privileges on stored
procedures. As result such privileges could have been lost after a rename
(i.e. not associated with the new name of user) and inherited by a new
user with the same name as the old name of the original user.
This problem was caused by code handling RENAME USER in
handle_grant_struct() which [sic!]:
a) tried to update wrong (tables) hash when updating stored procedure
privileges for new user name.
b) passed wrong arguments to function performing the hash update and
didn't take into account the way in which such update could have
changed the order of the hash elements.
This patch solves this problem by ensuring that a) the correct hash
is updated, b) correct arguments are used for the hash_update()
function and c) we take into account possible changes in the order
of hash elements.
Also fix bug#59110: Memory leak of QUICK_SELECT_I allocated memory.
Includes Jørgen Lølands review comments.
Root cause of these bugs are that test_if_skip_sort_order() decided to
revert the 'skip_sort_order' descision (and use filesort) after the
query plan has been updated to reflect a 'skip' of the sort order.
This might happen in 'check_reverse_order:' if we have a
select->quick which could not be made descending by appending
a QUICK_SELECT_DESC. ().
The original 'save_quick' was then restored after the QEP has been modified,
which caused:
- An incorrect 'precomputed_group_by= TRUE' may have been set,
and not reverted, as part of the already modifified QEP (Bug#59308)
- A 'select->quick' might have been created which we fail to delete (bug#59110).
This fix is a refactorication of test_if_skip_sort_order() where all logic
related to modification of QEP (controlled by argument 'bool no_changes'), is
moved to the end of test_if_skip_sort_order(), and done after *all* 'test_if_skip'
checks has been performed - including the 'check_reverse_order:' checks.
The refactorication above contains now intentional changes to the logic which
has been moved to the end of the function.
Furthermore, a smaller part of the fix address the handling of the
select->quick objects which may already exists when we call
'test_if_skip_sort_order()' (save_quick) -and
new select->quick's created during test_if_skip_sort_order():
- Before new select->quick may be created by calling ::test_quick_select(), we
set 'select->quick= 0' to avoid that ::test_quick_select() prematurely
delete the save_quick's. (After this call we may have both a 'save_quick'
and 'select->quick')
- All returns from ::test_if_skip_sort_order() where we may have both a
'save_quick' and a 'select->quick' has been changed to goto's to the
exit points 'skiped_sort_order:' or 'need_filesort:' where we
decide which of the QUICK_SELECT's to keep, and delete the other.
if the standard input is a directory.
The problem is that mysql monitor try to read from stdin without
checking input source type.
The solution is to stop reading data from standard input if a call
to read(2) failed.
A new test case was added into mysql.test.
handling.
The problem was that parsing of nested regular expression involved
recursive calls. Such recursion didn't take into account the amount of
available stack space, which ended up leading to stack overflow crashes.
