------------------------------------------------------------
revno: 3476
committer: Sunny Bains <Sunny.Bains@Oracle.Com>
branch nick: 5.1-security
timestamp: Thu 2010-08-05 19:18:17 +1000
message:
Fix bug# 55543 - InnoDB Plugin: Signal 6: Assertion failure in file fil/fil0fil.c line 4306
The bug is due to a double delete of a BLOB, once via:
rollback -> btr_cur_pessimistic_delete()
and the second time via purge.
The bug is in row_upd_clust_rec_by_insert(). There we relinquish ownership
of the non-updated BLOB columns in btr_cur_mark_extern_inherited_fields()
before building the row entry that will be inserted and whose contents will
be logged in the UNDO log. However, we don't set the BLOB column later to
INHERITED so that a possible rollback will not free the original row's
non-updated BLOB entries. This is because the condition that checks for
that is in :
if (node->upd_ext) {}.
node->upd_ext is non-NULL only if a BLOB column was updated and that column
is part of some key ordering (see row_upd_replace()). This results in the
non-update BLOB columns being deleted during a rollback and subsequently by
purge again.
rb://413
Handle overflow when reading value from SELECT MAX(C) FROM T;
Call ha_innobase::info() after initializing the autoinc value
in ha_innobase::open().
Fix for both the builtin and plugin.
rb://402
Merge from mysql-5.1-security.
The CONVERT_TZ function crashes the server when the
timezone argument is an empty SET field value.
1) The CONVERT_TZ may find a timezone string in the
tz_names hash.
2) A string representation of the empty SET is a
String of zero length with the NULL pointer.
3) If the key argument length is zero, hash functions
do comparison using the length of the record being
compared against.
I.e. a zero-length String buffer is an invalid
argument for hash search functions, and if String
points to NULL buffer, hashcmp() fails with SEGV
accessing that memory.
The my_tz_find function has been modified to
treat empty Strings as invalid timezone values
to skip unnecessary hash search.
mysql-test/r/timezone2.result:
Test case for bug #55424.
mysql-test/t/timezone2.test:
Test case for bug #55424.
sql/sql_string.h:
Bug #55424: convert_tz crashes when fed invalid data
Added "const" modifier to String::is_empty().
sql/tztime.cc:
Bug #55424: convert_tz crashes when fed invalid data
The my_tz_find function has been modified to
treat empty Strings as invalid timezone values
to skip unnecessary hash search.
Handle overflow when reading value from SELECT MAX(C) FROM T;
Call ha_innobase::info() after initializing the autoinc value
in ha_innobase::open().
Fix for both the builtin and plugin.
rb://402
The bug is due to a double delete of a BLOB, once via:
rollback -> btr_cur_pessimistic_delete()
and the second time via purge.
The bug is in row_upd_clust_rec_by_insert(). There we relinquish ownership
of the non-updated BLOB columns in btr_cur_mark_extern_inherited_fields()
before building the row entry that will be inserted and whose contents will
be logged in the UNDO log. However, we don't set the BLOB column later to
INHERITED so that a possible rollback will not free the original row's
non-updated BLOB entries. This is because the condition that checks for
that is in :
if (node->upd_ext) {}.
node->upd_ext is non-NULL only if a BLOB column was updated and that column
is part of some key ordering (see row_upd_replace()). This results in the
non-update BLOB columns being deleted during a rollback and subsequently by
purge again.
rb://413
The enum system variables were handled inconsistently
as ints, unsigned int and unsigned long on various places.
This caused problems on platforms on which
sizeof(int) != sizeof(long).
Fixed by homogenizing the type of the enum variables
to unsigned int, since it's size compatible with the C enum
type.
Removed the test from the experimental list.
The problem reported in BUG#55625 does not happen in mysql-trunk
when the logging format is row. However, a "CREATE SELECT" that
fails when the logging format is statement is not written to
the binary log.
This problem will be addressed in BUG#47899.
With statement- or mixed-mode logging, "LOAD DATA INFILE" queries
are written to the binlog using special types of log events.
When mysqlbinlog reads such events, it re-creates the file in a
temporary directory with a generated filename and outputs a
"LOAD DATA INFILE" query where the filename is replaced by the
generated file. The temporary file is not deleted by mysqlbinlog
after termination.
To fix the problem, in mixed mode we go to row-based. In SBR, we
document it to remind user the tmpfile is left in a temporary
directory.
mysql-test/suite/binlog/r/binlog_mixed_load_data.result:
Test result for BUG#34283.
mysql-test/suite/binlog/t/binlog_killed_simulate.test:
Updated for BUg#34283
mysql-test/suite/binlog/t/binlog_mixed_load_data.test:
Added the test file to verify that 'load data infile...' statement
will go to row-based in mixed mode.
mysql-test/suite/binlog/t/binlog_stm_blackhole.test:
Updated for BUg#34283
mysql-test/suite/rpl/r/rpl_innodb_mixed_dml.result:
Updated for Bug#34283
mysql-test/suite/rpl/t/rpl_loaddata.test:
Updated for Bug#34283
mysql-test/suite/rpl/t/rpl_loaddata_fatal.test:
Updated for Bug#34283
mysql-test/suite/rpl/t/rpl_loaddata_map.test:
Updated for Bug#34283
mysql-test/suite/rpl/t/rpl_slave_load_remove_tmpfile.test:
Updated for Bug#34283
mysql-test/suite/rpl/t/rpl_stm_log.test:
Updated for B
mysys/stacktrace.c:
Auto merge
sql/sql_lex.cc:
Auto merg
sql/sql_load.cc:
Added code to go to row-based in mixed mode for
'load data infile ...' statement
With statement- or mixed-mode logging, "LOAD DATA INFILE" queries
are written to the binlog using special types of log events.
When mysqlbinlog reads such events, it re-creates the file in a
temporary directory with a generated filename and outputs a
"LOAD DATA INFILE" query where the filename is replaced by the
generated file. The temporary file is not deleted by mysqlbinlog
after termination.
To fix the problem, in mixed mode we go to row-based. In SBR, we
document it to remind user the tmpfile is left in a temporary
directory.
mysql-test/extra/rpl_tests/rpl_loaddata.test:
Updated for Bug#34283
mysql-test/suite/binlog/r/binlog_mixed_load_data.result:
Test result for BUG#34283.
mysql-test/suite/binlog/t/binlog_killed_simulate.test:
Updated for Bug#34283
mysql-test/suite/binlog/t/binlog_mixed_load_data.test:
Added the test file to verify that 'load data infile...' statement
will go to row-based in mixed mode.
mysql-test/suite/binlog/t/binlog_stm_blackhole.test:
Updated for Bug#34283
mysql-test/suite/rpl/r/rpl_innodb_mixed_dml.result:
Updated for Bug#34283
mysql-test/suite/rpl/t/rpl_loaddata_fatal.test:
Updated for Bug#34283
mysql-test/suite/rpl/t/rpl_loaddata_map.test:
Updated for Bug#34283
mysql-test/suite/rpl/t/rpl_slave_load_remove_tmpfile.test:
Updated for Bug#34283
mysql-test/suite/rpl/t/rpl_stm_log.test:
Updated for Bug#34283
sql/sql_load.cc:
Added code to go to row-based in mixed mode for
'load data infile ...' statement
A CREATE...SELECT that fails is written to the binary log if a non-transactional
statement is updated. If the logging format is ROW, the CREATE statement and the
changes are written to the binary log as distinct events and by consequence the
created table is not rolled back in the slave.
In this patch, we opted to let the slave goes out of sync by not writting to the
binary log the CREATE statement. We do this by simply reseting the binary log's
cache.
mysql-test/suite/rpl/r/rpl_drop.result:
Added a test case.
mysql-test/suite/rpl/t/rpl_drop.test:
Added a test case.
sql/log.cc:
Introduced a function to clean up the cache.
sql/log.h:
Introduced a function to clean up the cache.
sql/sql_insert.cc:
Cleaned up the binary log cache if a CREATE...SELECT fails.
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.
******
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.
mysql-test/r/func_misc.result:
Test case for bug #54461.
******
Test case for bug #54461.
mysql-test/t/func_misc.test:
Test case for bug #54461.
******
Test case for bug #54461.
sql/item_func.cc:
Bug #54461: crash with longblob and union or update with subquery
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.
******
Bug #54461: crash with longblob and union or update with subquery
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.
Fix compiler warnings.
mysys/stacktrace.c:
Tag unused parameters.
sql/sql_lex.cc:
Variable becomes unused in non-debug builds. Also, no need to
assert the obvious.
******
This patch fixes the following bugs:
- Bug#5889: Exit handler for a warning doesn't hide the warning in
trigger
- Bug#9857: Stored procedures: handler for sqlwarning ignored
- Bug#23032: Handlers declared in a SP do not handle warnings generated
in sub-SP
- Bug#36185: Incorrect precedence for warning and exception handlers
The problem was in the way warnings/errors during stored routine execution
were handled. Prior to this patch the logic was as follows:
- when a warning/an error happens: if we're executing a stored routine,
and there is a handler for that warning/error, remember the handler,
ignore the warning/error and continue execution.
- after a stored routine instruction is executed: check for a remembered
handler and activate one (if any).
This logic caused several problems:
- if one instruction generates several warnings (errors) it's impossible
to choose the right handler -- a handler for the first generated
condition was chosen and remembered for activation.
- mess with handling conditions in scopes different from the current one.
- not putting generated warnings/errors into Warning Info (Diagnostic
Area) is against The Standard.
The patch changes the logic as follows:
- Diagnostic Area is cleared on the beginning of each statement that
either is able to generate warnings, or is able to work with tables.
- at the end of a stored routine instruction, Diagnostic Area is left
intact.
- Diagnostic Area is checked after each stored routine instruction. If
an instruction generates several condition, it's now possible to take a
look at all of them and determine an appropriate handler.
mysql-test/r/signal.result:
Update result file:
1. handled conditions are not cleared any more;
2. reflect changes in signal.test
mysql-test/r/signal_demo3.result:
Update result file: handled conditions are not cleared any more.
Due to playing with max_error_count, resulting warning lists
have changed.
mysql-test/r/sp-big.result:
Update result file: handled conditions are not cleared any more.
mysql-test/r/sp-bugs.result:
Update result file: handled conditions are not cleared any more.
mysql-test/r/sp-code.result:
Update result file:
1. handled conditions are not cleared any more.
2. add result for a new test case in sp-code.test.
mysql-test/r/sp-error.result:
Update result file:
1. handled conditions are not cleared any more.
2. add result for a new test case in sp-error.test.
mysql-test/r/sp.result:
Update result file: handled conditions are not cleared any more.
mysql-test/r/sp_trans.result:
Update result file: handled conditions are not cleared any more.
mysql-test/r/strict.result:
Update result file: handled conditions are not cleared any more.
mysql-test/r/view.result:
Update result file: handled conditions are not cleared any more.
mysql-test/suite/funcs_1/r/innodb_storedproc_02.result:
Update result file: handled conditions are not cleared any more.
mysql-test/suite/funcs_1/r/memory_storedproc_02.result:
Update result file: handled conditions are not cleared any more.
mysql-test/suite/funcs_1/r/myisam_storedproc_02.result:
Update result file: handled conditions are not cleared any more.
mysql-test/suite/funcs_1/r/storedproc.result:
Update result file: handled conditions are not cleared any more.
mysql-test/suite/rpl/r/rpl_row_sp005.result:
Update result file: handled conditions are not cleared any more.
mysql-test/suite/rpl/r/rpl_row_sp006_InnoDB.result:
Update result file: handled conditions are not cleared any more.
mysql-test/suite/rpl/r/rpl_row_trig003.result:
Update result file: handled conditions are not cleared any more.
mysql-test/t/signal.test:
Make a test case more readable in the result file.
mysql-test/t/sp-code.test:
Add a test case for Bug#23032 checking that
No Data takes precedence on Warning.
mysql-test/t/sp-error.test:
Adding test cases for:
- Bug#23032
- Bug#36185
- Bug#5889
- Bug#9857
mysql-test/t/sp.test:
Fixing test case to reflect behavioral changes made by the patch.
sql/sp_head.cc:
Reset the per-statement warning count before executing
a stored procedure instruction.
Move to a separate function code which checks the
completion status of the executed statement and searches
for a handler.
Remove redundant code now that search for a handler is
done after execution, errors are always pushed.
sql/sp_pcontext.h:
Remove unused code.
sql/sp_rcontext.cc:
- Polish sp_rcontext::find_handler(): use sp_rcontext::m_hfound instead
of an extra local variable;
- Remove sp_rcontext::handle_condition();
- Introduce sp_rcontext::activate_handler(), which prepares
previously found handler for execution.
- Move sp_rcontext::enter_handler() code into activate_handler(),
because enter_handler() is used only from there;
- Cleanups;
- Introduce DBUG_EXECUTE_IF() for a test case in sp-code.test
sql/sp_rcontext.h:
- Remove unused code
- Cleanups
sql/sql_class.cc:
Merge THD::raise_condition_no_handler() into THD::raise_condition().
After the patch raise_condition_no_handler() was called
in raise_condition() only.
sql/sql_class.h:
Remove raise_condition_no_handler().
sql/sql_error.cc:
Remove Warning_info::reserve_space() -- handled conditions are not
cleared any more, so there is no need for RESIGNAL to re-push them.
sql/sql_error.h:
Remove Warning_info::reserve_space().
sql/sql_signal.cc:
Handled conditions are not cleared any more,
so there is no need for RESIGNAL to re-push them.
In order to be able to check if the set of the grouping fields in a
GROUP BY has changed (and thus to start a new group) the optimizer
caches the current values of these fields in a set of Cached_item
derived objects.
The Cached_item_str, used for caching varchar and TEXT columns,
is limited in length by the max_sort_length variable.
A String buffer to store the value with an alloced length of either
the max length of the string or the value of max_sort_length
(whichever is smaller) in Cached_item_str's constructor.
Then, at compare time the value of the string to compare to was
truncated to the alloced length of the string buffer inside
Cached_item_str.
This is all fine and valid, but only if you're not assigning
values near or equal to the alloced length of this buffer.
Because when assigning values like this the alloced length is
rounded up and as a result the next set of data will not match the
group buffer, thus leading to wrong results because of the changed
alloced_length.
Fixed by preserving the original maximum length in the
Cached_item_str's constructor and using this instead of the
alloced_length to limit the string to compare to.
Test case added.
