Bug #55755 : Date STD variable signness breaks server on FreeBSD and OpenBSD
* Added a check to configure on the size of time_t
* Created a macro to check for a valid time_t that is safe to use with datetime
functions and store in TIMESTAMP columns.
* Used the macro consistently instead of the ad-hoc checks introduced by 52315
* Fixed compliation warnings on platforms where the size of time_t is smaller than
the size of a long (e.g. OpenBSD 4.8 64 amd64).
Bug #52315: utc_date() crashes when system time > year 2037
* Added a correct check for the timestamp range instead of just variable size check to
SET TIMESTAMP.
* Added overflow checking before converting to time_t.
* Using a correct localized error message in this case instead of the generic error.
* Added a test suite.
* fixed the checks so that they check for unsigned time_t as well. Used the checks
consistently across the source code.
* fixed the original test case to expect the new error code.
primary_key_no == 0".
Attempt to create InnoDB table with non-nullable column of
geometry type having an unique key with length 12 on it and
with some other candidate key led to server crash due to
assertion failure in both non-debug and debug builds.
The problem was that such a non-candidate key could have
been sorted as the first key in table/.FRM, before any legit
candidate keys. This resulted in assertion failure in InnoDB
engine which assumes that primary key should either be the
first key in table/.FRM or should not exist at all.
The reason behind such an incorrect sorting was an wrong
value of Create_field::key_length member for geometry field
(which was set to its pack_length == 12) which confused code
in mysql_prepare_create_table(), so it would skip marking
such key as a key with partial segments.
This patch fixes the problem by ensuring that this member
gets the same value of Create_field::key_length member as
for other blob fields (from which geometry field class is
inherited), and as result unique keys on geometry fields
are correctly marked as having partial segments.
Root cause for this bug is that the optimizer try to detect&
optimize the special case:
'<field> BETWEEN c1 AND c1' and handle this as the condition '<field> = c1'
This was implemented inside add_key_field(.. *field, *value[]...)
which assumed field to refer key Field, and value[] to refer a [low...high]
constant pair. value[0] and value[1] was then compared for equality.
In a 'normal' BETWEEN condition of the form '<field> BETWEEN val1 and val2' the
BETWEEN operation is represented with an argementlist containing the
values [<field>, val1, val2] - add_key_field() is then called with
parameters field=<field>, *value=val1.
However, if the BETWEEN predicate specified:
1) '<const1> BETWEEN<const2> AND<field>
the 'field' and 'value' arguments to add_key_field() had to be swapped.
This was implemented by trying to cheat add_key_field() to handle it like:
2) '<const1> GE<const2> AND<const1> LE<field>'
As we didn't really replace the BETWEEN operation with 'ge' and 'le',
add_key_field() still handled it as a 'BETWEEN' and compared the (swapped)
arguments<const1> and<const2> for equality. If they was equal, the
condition 1) was incorrectly 'optimized' to:
3) '<field> EQ <const1>'
This fix moves this optimization of '<field> BETWEEN c1 AND c1' into
add_key_fields() which then calls add_key_equal_fields() to collect
key equality / comparison for the key fields in the BETWEEN condition.
Third updated patch - this version also includes copyright notice in added Perl script.
This patch implements a check for such modules at runtime. If modules are not found or unable to load, the test is skipped with
the following message:
[ skipped ] Test needs Perl modules DBI and DBD::mysql
Checks are done via a helper Perl script which looks for the module in a runtime environment that is as similar to that of the
mysqlhotcopy script as possible (thus not intended for Windows environments at this time).
The helper script tells mysql-test about the result by writing information to a temporary file that is later read by mysql-test.
See comments in added files (have_dbi_dbd-mysql.inc and checkDBI_DBD-mysql.pl) for details.
The patch also removes the mysqlhotcopy tests from the list of disabled tests.
In SBR, if a statement does not fail, it is always written to the binary
log, regardless if rows are changed or not. If there is a failure, a
statement is only written to the binary log if a non-transactional (.e.g.
MyIsam) engine is updated.
INSERT ON DUPLICATE KEY UPDATE and INSERT IGNORE were not following the
rule above and were not written to the binary log, if then engine was
Innodb.
There are two calls to read_log_event() on master in mysql_binlog_send().
Each call reads 19 bytes in this test case and the error of the second
read_log_event() is reported to the slave.
The second read_log_event() starts from position 94 (75 + 19) to 113
(75 + 19 + 19). Usually, there are two events in the binary log:
. 0 - 3 - Header
. 4 - 105 - Format Descriptor Event
. 106 - 304 - Query Event
and both reads fail because operations are reading from invalid positions
as expected.
However, mysql_binlog_send() does not use the same IO_CACHE that is used to
write into binary log (i.e. mysql_bin_log.log_file) for the hot binary log.
It opens the binary log file directly by calling open_binlog() and creates a
separated IO_CACHE. So there is a possibly that after a master has flushed
the binary log file, the content has been cached by the filesystem, and has
not updated the disk file. If this happens, then a slave will only see part
of the file, and thus the second read_log_event() will report event truncated
error.
To fix the problem, if the first read_log_event() has failed, we ensure that
the second one will try to read from the same position.
Regression introduced in bug#52455. Problem was that the
fixed function did not set the last used partition variable, resulting
in wrong partition used when storing the position of the newly
retrieved row.
Fixed by setting the last used partition in ha_partition::index_read_idx_map.
Race condition may occur: mtr sees the .expect file but it's empty
Fix: wait and try again if file is empty
Addendum: try again if line isn't 'wait' or 'restart'
Also added verbose printout of extra restart options
ZERO
When dates are represented internally as strings, i.e. when a string constant
is compared to a date value, both values are converted to long integers,
ostensibly for fast comparisons. DATE typed integer values are converted to
DATETIME by multiplying by 1,000,000 (each digit pair representing hour,
minute and second, respectively). But the mechanism did not distuinguish
cached INTEGER values, already in correct format, from newly converted
strings.
Fixed by marking the INTEGER cache as being of DATETIME format.
The test were using external tools not available for embedded.
Fixed by rewriting the test to not rely on external tools like the mysql-client
Also fixed some non portable --exec commands and replaced #p# to #P# to pass
on windows.
rpl_packet got a timeout failure sporadically on PB when stopping
slave. The real reason of this bug is that STOP SLAVE stopped
IO thread first and then stopped SQL thread. It was
possible that IO thread stopped after replicating part of a
transaction which SQL thread was executing. SQL thread would
be hung if the transaction could not be rolled back safely.
After this patch, STOP SLAVE will stop SQL thread first and then stop IO
thread, which guarantees that IO thread will fetch the reset of the
events of the transaction that SQL thread is executing, so that SQL
thread can finish the transaction if it cannot be rolled back safely.
Added below auxiliary files to make the test code neater.
restart_slave_sql.inc
rpl_connection_master.inc
rpl_connection_slave.inc
rpl_connection_slave1.inc
Undoing the patch, it complicates the code but is not the solution
I do not beleive newline mismatch could be the cause of this failure
First, I cannot see how this could be a problem, mtr ignores the newline
when reading the expect file, and the file is written and read on Windows.
Second, if this really was the problem it should have been deterministic:
either the newline is correctly interepreted or it is not.
Problem: the scanner function tested for strings "<![CDATA[" and
"-->" without checking input string boundaries, which led to valgrind's
"Conditional jump or move depends on uninitialised value(s)" error.
Fix: Adding boundary checking.
@ mysql-test/r/xml.result
@ mysql-test/t/xml.test
Adding test
@ strings/xml.c
Adding a helper function my_xml_parser_prefix_cmp(),
with input string boundary check.
Committing After latest merge.
Modified check_pct procedure to check return value of wait condition instead
of calling "dirty_pct".
Adding Review comments:
1) Added comment for success variable value
2) Procedure check_pct changed For Adding BOOLEAN input and SELECT QUERY Change
Introduced by the fix for bug#44766.
Problem: it's not correct to use args[0]->str_value as a buffer,
because args[0] may need this buffer for its own purposes.
Fix: adding a new class member tmp_value to use as return value.
@ mysql-test/r/ctype_many.result
@ mysql-test/t/ctype_many.test
Adding tests
@ sql/item_strfunc.cc
Changing code into traditional style:
use "str" as a buffer for the argument and tmp_value for the result value.
@ sql/item_strfunc.h
Adding tmp_value
Problem: when processing a query like:
SELECT '' LIKE '1' ESCAPE COUNT(1);
escape_item->val_str() was never executed and the "escape" class member
stayed initialized, which led to valgrind uninitialized memory error.
Note, a query with some tables in "FROM" clause
returns ER_WRONG_ARGUMENTS in the same situation:
SELECT '' LIKE '1' ESCAPE COUNT(1) FROM t1;
ERROR 1210 (HY000): Incorrect arguments to ESCAPE
Fix: disallowing using aggregate functions in ESCAPE clause,
even if there are no tables used. There is no much use of that anyway.
When mysqldadmin is run with sleep and count options,
it goes into an infinite loop and keeps executing the
specified command.
This happened because the statement, responsible for
decrementing the count value, was missing.
Fixed by adding a statement which will decrement the
count value for each iteration.
Backport to 5.0.
/*![:version:] Query Code */, where [:version:] is a sequence of 5
digits representing the mysql server version(e.g /*!50200 ... */),
is a special comment that the query in it can be executed on those
servers whose versions are larger than the version appearing in the
comment. It leads to a security issue when slave's version is larger
than master's. A malicious user can improve his privileges on slaves.
Because slave SQL thread is running with SUPER privileges, so it can
execute queries that he/she does not have privileges on master.
This bug is fixed with the logic below:
- To replace '!' with ' ' in the magic comments which are not applied on
master. So they become common comments and will not be applied on slave.
- Example:
'INSERT INTO t1 VALUES (1) /*!10000, (2)*/ /*!99999 ,(3)*/
will be binlogged as
'INSERT INTO t1 VALUES (1) /*!10000, (2)*/ /* 99999 ,(3)*/
IA64 and some other arcitectures use different float rounding mode and
i find no decent way to make it consistent.
So the test changed to be insensitive to this.
per-file messages:
mysql-test/t/gis.test
Bug#52208 gis fails on some platforms (Solaris, HP-UX, Linux)
--replace_result added
"rows examined" estimates". This change implements "innodb_stats_method"
with options of "nulls_equal", "nulls_unequal" and "null_ignored".
rb://553 approved by Marko
Without this patch mysqlhotcopy tests would fail due to not finding the mysqlhotcopy tool in release-like builds.
With this patch the tests would either pass, or fail due to missing Perl modules (see 56817).
Text conflict in mysql-test/mysql-test-run.pl:
- resolved by using logic from 5.5 to find mysqlhotcopy, the intention of this backport. Changed bindir to basedir.
When mysqldump tries to dump information in xml format,
the result does not contain field level comments.
In order to retrieve various informations for a field/column,
mysqldump currently uses 'show fields from <tab>' statement.
The attributes returned by the statement lacks the information
regarding field comments.
Fixed by changing the query to one that probes I_S to retrieve
required field informations, including the field comment.
Backported the fix to 5.1.
Problem: the auxiliary test files rpl_start_server.inc and rpl_stop_server.inc
write a file that is later read by mtr. The bug was that the file was written
with platform-dependent newline terminators, i.e., \r\n on windows, whereas mtr
only understands \n.
Fix: write the file so that it uses \n on all platforms.
other crashes
Some string manipulating SQL functions use a shared string object intended to
contain an immutable empty string. This object was used by the SQL function
SUBSTRING_INDEX() to return an empty string when one argument was of the wrong
datatype. If the string object was then modified by the sql function INSERT(),
undefined behavior ensued.
Fixed by instead modifying the string object representing the function's
result value whenever string manipulating SQL functions return an empty
string.
Relevant code has also been documented.
The test case fails with out of memory while updating a table
with several multi-megabytes sized rows. This can probably be too
exhausting for PB2 env.
The quick fix here is to reduce the size of the biggest
row (256MB) so that it becomes a little smaller (64MB).
INVOKER-security view access check wrong".
When privilege checks were done for tables used from an
INVOKER-security view which in its turn was used from
a DEFINER-security view connection's active security
context was incorrectly used instead of security context
with privileges of the second view's creator.
This meant that users which had enough rights to access
the DEFINER-security view and as result were supposed to
be able successfully access it were unable to do so in
cases when they didn't have privileges on underlying tables
of the INVOKER-security view.
This problem was caused by the fact that for INVOKER-security
views TABLE_LIST::security_ctx member for underlying tables
were set to 0 even in cases when particular view was used from
another DEFINER-security view. This meant that when checks of
privileges on these underlying tables was done in
setup_tables_and_check_access() active connection security
context was used instead of context corresponding to the
creator of caller view.
This fix addresses the problem by ensuring that underlying
tables of an INVOKER-security view inherit security context
from the view and thus correct security context is used for
privilege checks on underlying tables in cases when such view
is used from another view with DEFINER-security.
Item_func_spatial_collection::fix_length_and_dec didn't call parent's method, so
the maybe_null was set to '0' after it. But in this case the result was
just NULL, that caused wrong behaviour.
per-file comments:
mysql-test/r/gis.result
Bug #57321 crashes and valgrind errors from spatial types
test result updated.
mysql-test/t/gis.test
Bug #57321 crashes and valgrind errors from spatial types
test case added.
sql/item_geofunc.h
Bug #57321 crashes and valgrind errors from spatial types
Item_func_geometry::fix_length_and_dec() called in
Item_func_spatial_collection::fix_length_and_dec().
get_year_value() contains code to convert 2-digits year to
4-digits. The fix for Bug#49910 added a check on the size of
the underlying field so that this conversion is not done for
YEAR(4) values. (Since otherwise one would convert invalid
YEAR(4) values to valid ones.)
The existing check does not work when Item_cache is used, since
it is not detected when the cache is based on a Field. The
reported change in behavior is due to Bug#58030 which added
extra cached items in min/max computations.
The elegant solution would be to implement
Item_cache::real_item() to return the underlying Item.
However, some side effects are observed (change in explain
output) that indicates that such a change is not straight-
forward, and definitely not appropriate for an MRU.
Instead, a Item_cache::field() method has been added in order
to get access to the underlying field. (This field() method
eliminates the need for Item_cache::eq_def() used in
test_if_ref(), but in order to limit the scope of this fix,
that code has been left as is.)
tmptable needed
The function DEFAULT() works by modifying the the data buffer pointers (often
referred to as 'record' or 'table record') of its argument. This modification
is done during name resolution (fix_fields().) Unfortunately, the same
modification is done when creating a temporary table, because default values
need to propagate to the new table.
Fixed by skipping the pointer modification for fields that are arguments to
the DEFAULT function.
multiple columns in the partition key
ndb crash if duplicate columns in the partitioning key.
Backport from mysql-5.1-telco-7.0, see bug#53354.
Changed from case sensitive field name comparision
to non case sensitive too.
This assert could be triggered if -1 was inserted into
an auto increment column by a statement writing more than
one row.
Unless explicitly given, an interval of auto increment values
is generated when a statement first needs an auto increment
value. The triggered assert checks that the auto increment
counter is equal to or higher than the lower bound of this
interval.
Generally, the auto increment counter starts at 1 and is
incremented by 1 each time it is used. However, inserting an
explicit value into the auto increment column, sets the auto
increment counter to this value + 1 if this value is higher
than the current value of the auto increment counter.
This bug was triggered if the explicit value was -1. Since the
value was converted to unsigned before any comparisons were made,
it was found to be higher than the current vale of the auto
increment counter and the counter was set to -1 + 1. This value
was below the reserved interval and caused the assert to be
triggered the next time the statement tried to write a row.
With the patch for Bug#39828, this bug is no longer repeatable.
Now, -1 + 1 is detected as an "overflow" which causes the auto
increment counter to be set to ULONGLONG_MAX. This avoids hitting
the assert for the next insert and causes a new interval of
auto increment values to be generated. This resolves the issue.
This patch therefore only contains a regression test and no code
changes. Test case added to auto_increment.test.
mysqlbinlog only prints "use $database" statements to its output stream
when the active default database changes between events. This will cause
"No Database Selected" error when dropping and recreating that database.
To fix the problem, we clear print_event_info->db when printing an event
of CREATE/DROP/ALTER database statements, so that the Query_log_event
after such statements will be printed with the use 'db' anyway except
transaction keywords.
- Removed files specific to compiling on OS/2
- Removed files specific to SCO Unix packaging
- Removed "libmysqld/copyright", text is included in documentation
- Removed LaTeX headers for NDB Doxygen documentation
- Removed obsolete NDB files
- Removed "mkisofs" binaries
- Removed the "cvs2cl.pl" script
- Changed a few GPL texts to use "program" instead of "library"
ASSERT happens due to improper calculation of the max_length
in Item_func_div object, if dividend has max_length == 0 then
Item_func_div::max_length is set to 0 under some circumstances.
The fix:
If decimals == NOT_FIXED_DEC then set
Item_func_div::max_length to max possible
DOUBLE length value.
Bug#57071: EXTRACT(WEEK from date_col) cannot be allowed as partitioning function
There were functions allowed as partitioning functions
that implicit allowed cast. That could result in unacceptable
behaviour.
Solution was to check that the arguments of date and time functions
have allowed types (field and date/datetime/time depending on function).
Problem: master executed a statement that would fail on slave
(namely, DROP USER 'create_rout_db'@'localhost').
Then the test did:
--let $rpl_only_running_threads= 1
--source include/rpl_reset.inc
rpl_reset.inc calls rpl_sync.inc, which first checks which of
the threads are running and then syncs those threads that are
running. If the SQL thread fails after the check, the sync will
fail. So there was a race in the test and it failed on some
slow hosts.
Fix: Don't replicate the failing statement.
Item_sum_max/Item_sum_min incorrectly set null_value flag and
attempt to get result in parent functions leads to crash.
This happens due to double evaluation of the function argumet.
First evaluation happens in the comparator and second one
happens in Item_cache::cache_value().
The fix is to introduce new Item_cache object which
holds result of the argument and use this cached value
as an argument of the comparator.
row_upd_changes_ord_field_binary(): Do not return TRUE if the update
vector changes a column that is covered by a prefix index, but does
not change the column prefix. Add the row_ext_t parameter for
determining whether the prefixes of externally stored columns match.
dfield_datas_are_binary_equal(): Add the parameter len, for comparing
column prefixes when len > 0.
innodb.test: Add a test case where the patch of Bug #55284 failed
without this fix.
rb:537 approved by Jimmy Yang
Normally, auto_increment value is generated for the column by
inserting either NULL or 0 into it. NO_AUTO_VALUE_ON_ZERO
suppresses this behavior for 0 so that only NULL generates
the auto_increment value. This behavior is also followed by
a slave, specifically by the SQL Thread, when applying events
in the statement format from a master. However, when applying
events in the row format, the flag was ignored thus causing
an assertion failure:
"Assertion failed: next_insert_id == 0, file .\handler.cc"
In fact, we never need to generate a auto_increment value for
the column when applying events in row format on slave. So we
don't allow it to happen by using 'MODE_NO_AUTO_VALUE_ON_ZERO'.
Refactoring: Get rid of all the sql_mode checks to rows_log_event
when applying it for avoiding problems caused by the inconsistency
of the sql_mode on slave and master as the sql_mode is not set for
Rows_log_event.
Problem: Warnings for truncated data were generated on hosts with
long host names because @@hostname was inserted into a CHAR(40) column.
Fix: Change CHAR(40) to TEXT.
Major replication test framework cleanup. This does the following:
- Ensure that all tests clean up the replication state when they
finish, by making check-testcase check the output of SHOW SLAVE STATUS.
This implies:
- Slave must not be running after test finished. This is good
because it removes the risk for sporadic errors in subsequent
tests when a test forgets to sync correctly.
- Slave SQL and IO errors must be cleared when test ends. This is
good because we will notice if a test gets an unexpected error in
the slave threads near the end.
- We no longer have to clean up before a test starts.
- Ensure that all tests that wait for an error in one of the slave
threads waits for a specific error. It is no longer possible to
source wait_for_slave_[sql|io]_to_stop.inc when there is an error
in one of the slave threads. This is good because:
- If a test expects an error but there is a bug that causes
another error to happen, or if it stops the slave thread without
an error, then we will notice.
- When developing tests, wait_for_*_to_[start|stop].inc will fail
immediately if there is an error in the relevant slave thread.
Before this patch, we had to wait for the timeout.
- Remove duplicated and repeated code for setting up unusual replication
topologies. Now, there is a single file that is capable of setting
up arbitrary topologies (include/rpl_init.inc, but
include/master-slave.inc is still available for the most common
topology). Tests can now end with include/rpl_end.inc, which will clean
up correctly no matter what topology is used. The topology can be
changed with include/rpl_change_topology.inc.
- Improved debug information when tests fail. This includes:
- debug info is printed on all servers configured by include/rpl_init.inc
- User can set $rpl_debug=1, which makes auxiliary replication files
print relevant debug info.
- Improved documentation for all auxiliary replication files. Now they
describe purpose, usage, parameters, and side effects.
- Many small code cleanups:
- Made have_innodb.inc output a sensible error message.
- Moved contents of rpl000017-slave.sh into rpl000017.test
- Added mysqltest variables that expose the current state of
disable_warnings/enable_warnings and friends.
- Too many to list here: see per-file comments for details.
Post-push fixes:
- fixed platform dependent result files
- appeasing valgrind warnings:
Fault injection was also uncovering a previously existing
potential mem leaks. For BUG#46166 testing purposes, fixed
by forcing handling the leak when injecting faults.
"load data infile .." allowed for access to
unautohorized tables.
Due to a faulty if-statement it was possible to
circumvent the secure_file_priv restriction.
file .\item_subselect.cc, line 836
IN quantified predicates are never executed directly. They are rather wrapped
inside nodes called IN Optimizers (Item_in_optimizer) which take care of the
execution. However, this is not done during query preparation. Unfortunately
the LIKE predicate pre-evaluates constant right-hand side arguments even
during name resolution. Likely this is meant as an optimization.
Fixed by not pre-evaluating LIKE arguments in view prepare mode.
Back-ported to 5.0s
The user-visible problem was that changes to column-level privileges,
happened in between of PREPARE and EXECUTE of a prepared statement, were
neglected. I.e. a prepared statement could be executed with the
column-level privileges as of PREPARE-time. The problem existed for
column-level privileges only.
A similar problem existed for stored programs: the changes between
executions didn't have an effect.
Technically the thing is that table references are cached in
Prepared_statement::prepare() call. In subsequent
Prepared_statement::execute() calls those cached values are used.
There are two functions to get a field by name: find_field_in_table() and
find_field_in_table_ref(). On prepare-phase find_field_in_table_ref() is
called, on execute-phase -- find_field_in_table() because the table is
cached. find_field_in_table() does not check column-level privileges and
expects the caller to do that. The problem was that this check was
forgotten.
The fix is to check them there as it happens in find_field_in_table_ref().
Original revid: alexey.kopytov@sun.com-20100723115254-jjwmhq97b9wl932l
> Bug #54476: crash when group_concat and 'with rollup' in
> prepared statements
>
> Using GROUP_CONCAT() together with the WITH ROLLUP modifier
> could crash the server.
>
> The reason was a combination of several facts:
>
> 1. The Item_func_group_concat class stores pointers to ORDER
> objects representing the columns in the ORDER BY clause of
> GROUP_CONCAT().
>
> 2. find_order_in_list() called from
> Item_func_group_concat::setup() modifies the ORDER objects so
> that their 'item' member points to the arguments list
> allocated in the Item_func_group_concat constructor.
>
> 3. In some cases (e.g. in JOIN::rollup_make_fields) a copy of
> the original Item_func_group_concat object could be created by
> using the Item_func_group_concat::Item_func_group_concat(THD
> *thd, Item_func_group_concat *item) copy constructor. The
> latter essentially creates a shallow copy of the source
> object. Memory for the arguments array is allocated on
> thd->mem_root, but the pointers for arguments and ORDER are
> copied verbatim.
>
> What happens in the test case is that when executing the query
> for the first time, after a copy of the original
> Item_func_group_concat object has been created by
> JOIN::rollup_make_fields(), find_order_in_list() is called for
> this new object. It then resolves ORDER BY by modifying the
> ORDER objects so that they point to elements of the arguments
> array which is local to the cloned object. When thd->mem_root
> is freed upon completing the execution, pointers in the ORDER
> objects become invalid. Those ORDER objects, however, are also
> shared with the original Item_func_group_concat object which is
> preserved between executions of a prepared statement. So the
> first call to find_order_in_list() for the original object on
> the second execution tries to dereference an invalid pointer.
>
> The solution is to create copies of the ORDER objects when
> copying Item_func_group_concat to not leave any stale pointers
> in other instances with different lifecycles.
Bug#57913 large negative number to string conversion functions crash
String object which is used as result container of the item
has uninitialized 'str_charset' field. This object
might be used later to preform some internal operations
and str_charset field is involved in these operations.
It leads to crash.
The fix is to intialize str_charset in my_decimal2string() func.
--Bug#52157 various crashes and assertions with multi-table update, stored function
--Bug#54475 improper error handling causes cascading crashing failures in innodb/ndb
--Bug#57703 create view cause Assertion failed: 0, file .\item_subselect.cc, line 846
--Bug#57352 valgrind warnings when creating view
--Recently discovered problem when a nested materialized derived table is used
before being populated and it leads to incorrect result
We have several modes when we should disable subquery evaluation.
The reasons for disabling are different. It could be
uselessness of the evaluation as in case of 'CREATE VIEW'
or 'PREPARE stmt', or we should disable subquery evaluation
if tables are not locked yet as it happens in bug#54475, or
too early evaluation of subqueries can lead to wrong result
as it happened in Bug#19077.
Main problem is that if subquery items are treated as const
they are evaluated in ::fix_fields(), ::fix_length_and_dec()
of the parental items as a lot of these methods have
Item::val_...() calls inside.
We have to make subqueries non-const to prevent unnecessary
subquery evaluation. At the moment we have different methods
for this. Here is a list of these modes:
1. PREPARE stmt;
We use UNCACHEABLE_PREPARE flag.
It is set during parsing in sql_parse.cc, mysql_new_select() for
each SELECT_LEX object and cleared at the end of PREPARE in
sql_prepare.cc, init_stmt_after_parse(). If this flag is set
subquery becomes non-const and evaluation does not happen.
2. CREATE|ALTER VIEW, SHOW CREATE VIEW, I_S tables which
process FRM files
We use LEX::view_prepare_mode field. We set it before
view preparation and check this flag in
::fix_fields(), ::fix_length_and_dec().
Some bugs are fixed using this approach,
some are not(Bug#57352, Bug#57703). The problem here is
that we have a lot of ::fix_fields(), ::fix_length_and_dec()
where we use Item::val_...() calls for const items.
3. Derived tables with subquery = wrong result(Bug19077)
The reason of this bug is too early subquery evaluation.
It was fixed by adding Item::with_subselect field
The check of this field in appropriate places prevents
const item evaluation if the item have subquery.
The fix for Bug19077 fixes only the problem with
convert_constant_item() function and does not cover
other places(::fix_fields(), ::fix_length_and_dec() again)
where subqueries could be evaluated.
Example:
CREATE TABLE t1 (i INT, j BIGINT);
INSERT INTO t1 VALUES (1, 2), (2, 2), (3, 2);
SELECT * FROM (SELECT MIN(i) FROM t1
WHERE j = SUBSTRING('12', (SELECT * FROM (SELECT MIN(j) FROM t1) t2))) t3;
DROP TABLE t1;
4. Derived tables with subquery where subquery
is evaluated before table locking(Bug#54475, Bug#52157)
Suggested solution is following:
-Introduce new field LEX::context_analysis_only with the following
possible flags:
#define CONTEXT_ANALYSIS_ONLY_PREPARE 1
#define CONTEXT_ANALYSIS_ONLY_VIEW 2
#define CONTEXT_ANALYSIS_ONLY_DERIVED 4
-Set/clean these flags when we perform
context analysis operation
-Item_subselect::const_item() returns
result depending on LEX::context_analysis_only.
If context_analysis_only is set then we return
FALSE that means that subquery is non-const.
As all subquery types are wrapped by Item_subselect
it allow as to make subquery non-const when
it's necessary.
Auto increment value wraps when performing a bulk insert with
auto_increment_increment and auto_increment_offset greater than
one.
The fix:
If overflow happened then return MAX_ULONGLONG value as an
indication of overflow and check this before storing the
value into the field in update_auto_increment().
Explain fails at fix_fields stage and some items are left unfixed,
particulary Item_group_concat. Item_group_concat::orig_args field
is uninitialized in this case and Item_group_concat::print call
leads to crash.
The fix:
move the initialization of Item_group_concat::orig_args
into constructor.
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.
When a query fails with a different error on the slave,
the sql thread outputs a message (M) containing:
1. the error message format for the master error code
2. the master error code
3. the error message for the slave's error code
4. the slave error code
Given that the slave has no information on the error message
itself that the master outputs, it can only print its own
version of the message format (but stripped from the
additional data if the message format requires). This may
confuse users.
To fix this we augment the slave's message (M) to explicitly
state that the master's message is actually an error message
format, the one associated with the given master error code
and that the slave server knows about.
When installing plugins, there is a missing check
for slash (/) in the path on Windows. Note that on
Windows, both / and \ can be used to separate
directories.
This patch fixes the issue by:
- Adding a FN_DIRSEP symbol for all platforms
consisting of a string of legal directory
separators.
- Adding a charset-aware version of strcspn().
- Adding a check_valid_path() function that uses
my_strcspn() to check if any FN_DIRSEP character
is in the supplied string.
- Using the check_valid_path() function in
sql_plugin.cc and sql_udf.cc (which means
replacing the existing test there).
when generating new name.
If find_uniq_filename returns an error, then this error is not
being propagated upwards, and execution does not report error to
the user (although a entry in the error log is generated).
Additionally, some more errors were ignored in new_file_impl:
- when writing the rotate event
- when reopening the index and binary log file
This patch addresses this by propagating the error up in the
execution stack. Furthermore, when rotation of the binary log
fails, an incident event is written, because there may be a
chance that some changes for a given statement, were not properly
logged. For example, in SBR, LOAD DATA INFILE statement requires
more than one event to be logged, should rotation fail while
logging part of the LOAD DATA events, then the logged data would
become inconsistent with the data in the storage engine.
InnoDB AUTOINC code expects the locks to be released in strict reverse order
at the end of the statement. However, nested stored proedures and partition
tables break this rule. We now allow the locks to be deleted from the
trx->autoinc_locks vector in any order but optimise for the common (old) case.
rb://441 Approved by Marko Makela
When using BINLOG statement to execute rows log events, session variables
foreign_key_checks and unique_checks are changed temporarily. As each rows
log event has their own special session environment and its own
foreign_key_checks and unique_checks can be different from current session
which executing the BINLOG statement. But these variables are not restored
correctly after BINLOG statement. This problem will cause that the following
statements fail or generate unexpected data.
In this patch, code is added to backup and restore these two variables.
So BINLOG statement will not affect current session's variables again.
win x86 debug_max
The windows MTR run exhibited a different test execution
ordering (due to the fact that in these platforms MTR is invoked
with --parallel > 1). This uncovered a bug in the aforementioned
test case, which is triggered by the following conditions:
1. server is not restarted between two different tests;
2. the test before binlog.binlog_row_failure_mixing_engines
issues flush logs;
3. binlog.binlog_row_failure_mixing_engines uses binlog
positions to limit the output of show_binlog_events;
4. binlog.binlog_row_failure_mixing_engines does not state which
binlog file to use, thence it uses a wrong binlog file with
the correct position.
There are two possible fixes: 1. make sure that the test start
from a clean slate - binlog wise; 2. in addition to the position,
also state the binary log file before sourcing
show_binlog_events.inc .
We go for fix#1, ie, deploy a RESET MASTER before the test is
actually started.
Problem: MySQL cp1251 did not support 'U+20AC EURO SIGN'
which was assigned a few years ago to 0x88.
Fix: adding mapping: 0x88 <-> U+20AC
@ mysql-test/include/ctype_8bit.inc
New shared file to test 8bit character sets.
@ mysql-test/r/ctype_cp1251.result
@ mysql-test/t/ctype_cp1251.test
Adding tests
@ sql/share/charsets/cp1251.xml
Adding mapping
@ strings/ctype-extra.c
Regenerating ctype-extra.c using strings/conf_to_src
according to new cp1251.xml
After dropping and recreating the database specified along with --one-database
option at command line, mysql client keeps filtering the statements even after
the execution of a 'USE' command on the same database.
--one-database option enables the filtering of statements when the current
database is not the one specified at the command line. However, when the same
database is dropped and recreated the variable (current_db) that holds the
inital database name gets altered. This bug exploits the fact that current_db
initially gets set to null value (0) when a 'use db_name' follows the recreation
of same database db_name (speficied at the command line) and hence skip_updates
gets set to 1, which inturn triggers the further filtering of statements.
Fixed by making get_current_db() a no-op function when one_database is set,
and hence, under that condition current_db will not get altered.
Note, however the value of current_db can change when we execute 'connect'
command with a differnet database to reconnect to the server, in which case,
the behavior of --one-database will be formulated using this new database.
It does work in general, the problem here was that the test name
'alter_table' matches 'main.alter_table-big' which has already been found.
Fixed by matching more explicitly (with/without suite name)
> revision-id: gshchepa@mysql.com-20100801181236-uyuq6ewaq43rw780
> parent: alexey.kopytov@sun.com-20100723115254-jjwmhq97b9wl932l
> committer: Gleb Shchepa <gshchepa@mysql.com>
> branch nick: mysql-5.1-security
> timestamp: Sun 2010-08-01 22:12:36 +0400
> Bug #54461: crash with longblob and union or update with subquery
>
> Queries may crash, if
> 1) the GREATEST or the LEAST function has a mixed list of
> numeric and LONGBLOB arguments and
> 2) the result of such a function goes through an intermediate
> temporary table.
>
> An Item that references a LONGBLOB field has max_length of
> UINT_MAX32 == (2^32 - 1).
>
> The current implementation of GREATEST/LEAST returns REAL
> result for a mixed list of numeric and string arguments (that
> contradicts with the current documentation, this contradiction
> was discussed and it was decided to update the documentation).
>
> The max_length of such a function call was calculated as a
> maximum of argument max_length values (i.e. UINT_MAX32).
>
> That max_length value of UINT_MAX32 was used as a length for
> the intermediate temporary table Field_double to hold
> GREATEST/LEAST function result.
>
> The Field_double::val_str() method call on that field
> allocates a String value.
>
> Since an allocation of String reserves an additional byte
> for a zero-termination, the size of String buffer was
> set to (UINT_MAX32 + 1), that caused an integer overflow:
> actually, an empty buffer of size 0 was allocated.
>
> An initialization of the "first" byte of that zero-size
> buffer with '\0' caused a crash.
>
> The Item_func_min_max::fix_length_and_dec() has been
> modified to calculate max_length for the REAL result like
> we do it for arithmetical operators.
If mysqltest dies, mtr waits to see if mysqld dies too within 100ms
But in that case, it should not care about expected crash
Fix: jump past the code that checks the expect file
OPTIMIZE TABLE recreates the whole table. That is why the counter gets reset.
Making the next autoinc column persistent is a separate issue from resetting
the value after an OPTIMIZE TABLE. We already have a check for ALTER TABLE
and CREATE INDEX to preserve the value on table recreate. We should be able to
add an additional check for OPTIMIZE TABLE to preserve the next value.
rb://519 Approved by Jimmy Yang.
Follow-up discussed with Reporter:
Avoid hard shutdown after test failure, if caused by server log warning
AND we are running valgrind
More general pick-up of valgrind summaries, order may apparently vary
Do exit(1) if we did find valgrind summary warnings
In case of low memory sort buffer QUICK_INDEX_MERGE_SELECT creates
temporary file where is stores row ids which meet QUICK_SELECT ranges
except of clustered pk range, clustered range is processed separately.
In init_read_record we check if temporary file is used and choose
appropriate record access method. It does not take into account that
temporary file contains partial result in case of QUICK_INDEX_MERGE_SELECT
with clustered pk range.
The fix is always to use rr_quick if QUICK_INDEX_MERGE_SELECT
with clustered pk range is used.
> revision-id: alexey.kopytov@sun.com-20100824103548-ikm79qlfrvggyj9h
> parent: sunny.bains@oracle.com-20100816001222-xqc447tr6jwh8c53
> committer: Alexey Kopytov <Alexey.Kopytov@Sun.com>
> branch nick: 5.1-security
> timestamp: Tue 2010-08-24 14:35:48 +0400
> message:
> Bug #55568: user variable assignments crash server when used
> within query
>
> The server could crash after materializing a derived table
> which requires a temporary table for grouping.
>
> When destroying the temporary table used to execute a query for
> a derived table, JOIN::destroy() did not clean up Item_fields
> pointing to fields in the temporary table. This led to
> dereferencing a dangling pointer when printing out the items
> tree later in the outer SELECT.
>
> The solution is an addendum to the patch for bug37362: in
> addition to cleaning up items in tmp_all_fields3, do the same
> for items in tmp_all_fields1, since now we have an example
> where this is necessary.
Problem: crash in Item_float constructor on DBUG_ASSERT due
to not null-terminated string parameter.
Fix: making Item_float::Item_float non-null-termintated parameter safe:
- Using temporary buffer when generating error
modified:
@ mysql-test/r/xml.result
@ mysql-test/t/xml.test
@ sql/item.cc
ESCAPE argument might be empty string. It leads
to server crash under some circumstances.
The fix:
-added check if ESCAPE argument result is not empty string
Problem: When GET_FORMAT() is called two times from the upper
level function (e.g. LEAST in the bug report), on the second
call "res= args[0]->val_str(...)" and str point to the same
String object.
1. Fix: changing the order from
- get val_str into tmp_value then convert to str
to
- get val_str into str then convert to tmp_value
The new order is more correct: the purpose of "str" parameter
is exactly to call val_str() for arguments.
The purpose of String class members (like tmp_value) is to do further
actions on the result.
Doing it in the other way around give unexpected surprises.
2. Using str_value instead of str to do padding, for the same reason.
Bug#55794: ulonglong options of mysqld show wrong values.
Port the few remaining system variables to the correct mechanism --
range-check in check-stage (and throw error or warning at that point
as needed and depending on STRICTness), update in update stage.
Fix some signedness errors when retrieving sysvar values for display.
Bug#57820 extractvalue crashes
Problem: ExtractValue and Replace crashed in some cases
due to invalid handling of empty and NULL arguments.
Per file comments:
@mysql-test/r/ctype_ujis.result
@mysql-test/r/xml.result
@mysql-test/t/ctype_ujis.test
@mysql-test/t/xml.test
Adding tests
@sql/item_strfunc.cc
Make sure Item_func_replace::val_str safely handles empty strings.
@sql/item_xmlfunc.cc
set null_value if nodeset_func returned NULL,
which is possible when the second argument is an
unset user variable.
MySQL 5.1 server
Server used to clip overly long user-names. This was presumably lost
when code was made UTF8-clean.
Now we emulate the behaviour for backward compatibility, but UTF8-ly
correct.
The test result differs on windows, since
it writes out 'localhost:<port>' instead of
only 'localhost', since it uses tcp/ip instead
of unix sockets on windows.
Fixed by replacing that column.
Also requires --big-test from some long running tests
and added a weekly run of all test requiring --big-test.
with on duplicate key update
There was a missed corner case in the partitioning
handler, which caused the next_insert_id to be changed
in the second level handlers (i.e the hander of a partition),
which caused this debug assertion.
The solution was to always ensure that only the partitioning
level generates auto_increment values, since if it was done
within a partition, it may fail to match the partition
function.
in different default schema.
In strict mode, when data truncation or conversion happens,
THD::killed is set to THD::KILL_BAD_DATA.
This is abuse of KILL mechanism to guarantee that execution
of statement is aborted.
The stored procedures execution, on the other hand,
upon detection that a connection was killed, would
terminate immediately, without trying to restore the caller's
context, in particular, restore the caller's current schema.
The fix is, when terminating a stored procedure execution,
to only bypass cleanup if the entire connection was killed,
not in case of other forms of KILL.
ALTER TABLE RENAME, DISABLE KEYS.
The code of ALTER TABLE RENAME, DISABLE KEYS could
issue a commit while holding LOCK_open mutex.
This is a regression introduced by the fix for
Bug 54453.
This failed an assert guarding us against a potential
deadlock with connections trying to execute
FLUSH TABLES WITH READ LOCK.
The fix is to move acquisition of LOCK_open outside
the section that issues ha_autocommit_or_rollback().
LOCK_open is taken to protect against concurrent
operations with .frms and the table definition
cache, and doesn't need to cover the call to commit.
A test case added to innodb_mysql.test.
The patch is to be null-merged to 5.5, which
already has 54453 null-merged to it.
Problem: a flaw (derefencing a NULL pointer) in the LIKE optimization
code may lead to a server crash in some rare cases.
Fix: check the pointer before its dereferencing.
sporadically.
The cause of the sporadic time out was a leaking protection
against the global read lock, taken by the RENAME statement,
and not released in case of an error occurred during RENAME.
The leaking protection counter would lead to the value of
protect_against_global_read never dropping to 0.
Consequently FLUSH TABLES in all connections, including the
one that leaked the protection, could not proceed.
The fix is to ensure that all branchesin RENAME code properly
release GRL protection.
There were actually more problems in this area:
Slaves (if any) were unconditionally restarted, this appears unnecessary.
Sort criteria were suboptimal, included the test name.
Added logic to "reserve" a sequence of tests with same config for one thread
Got rid of sort_criteria hash, put it into the test case itself
Adds little sanity check that expected worker picks up test
Fixed some tests that may fail if starting on running server
Some of these fail only if *same* test is repeated.
Finally, special sorting of tests that do --force-restart
removed and replaced by the comprehensive innodb-create-options.test.
It uses the rules listed in the comments at the top of that test.
This patch introduces these differences from previous behavior;
1) KEY_BLOCK_SIZE=0 is allowed by Innodb in both strict and non-strict mode
with no errors or warnings. It was previously used by the server to set
KEY_BLOCK_SIZE to undefined. (Bug#56628)
2) An explicit valid non-DEFAULT ROW_FORMAT always takes priority over a
valid KEY_BLOCK_SIZE. (bug#56632)
3) Automatic use of COMPRESSED row format is only done if the ROW_FORMAT
is DEFAULT or unspecified.
4) ROW_FORMAT=FIXED is prevented in strict mode.
This patch also includes various formatting changes for consistency with
InnoDB coding standards.
Related Bugs
Bug#54679: ALTER TABLE causes compressed row_format to revert to compact
Bug#56628: ALTER TABLE .. KEY_BLOCK_SIZE=0 produces untrue warning or unnecessary error
Bug#56632: ALTER TABLE implicitly changes ROW_FORMAT to COMPRESSED
Replace the array of mutexes that used to protect
dict_index_t::stat_n_diff_key_vals[] with an array of rw locks that protects
all the stats related members in dict_table_t and all of its indexes.
Approved by: Jimmy (rb://503)
