buf_flush_try_neighbors(): Before invoking buf_page_t::ready_for_flush(),
check that the freshly looked up buf_pool.page_hash entry actually is
a buffer page and not a buf_pool.watch[] sentinel for purge buffering.
This race condition was introduced in MDEV-15053
(commit b1ab211dee).
It is rather hard to hit this bug, because
buf_flush_check_neighbors() already checked the condition.
The problem exists if buf_pool.watch_set() was invoked for
a page in the range after the check in buf_flush_check_neighbor()
had been finished.
Invoking memcpy() on a NULL pointer is undefined behaviour
(even if the length is 0) and gives the compiler permission to
assume that the pointer is nonnull. Recent versions of GCC
(starting with version 8) are more aggressively optimizing away
checks for NULL pointers. This undefined behaviour would cause
a SIGSEGV in the test main.func_encrypt on an optimized debug build
on GCC 10.2.0.
The issue here was the system variable max_sort_length was being applied
to decimals and it was truncating the value for decimals to the number
of bytes set by max_sort_length.
This was leading to a buffer overflow as the values were written
to the buffer without truncation and then we moved the offset to
the number of bytes(set by max_sort_length), that are needed for comparison.
The fix is to not apply max_sort_length for fixed size types like INT,
DECIMALS and only apply max_sort_length for CHAR, VARCHARS, TEXT and
BLOBS.
Also, revert the work-around for the test that was attempted in
commit 85613a3247.
This issue was caught by MemorySanitizer as well as on the
Microsoft Windows debug builds, thanks to /MD being used
starting with 10.4.
The code fix will also be applied to 10.2 because the regression
was introduced in commit afc9d00c66.
The crash happens because a double free in the case CREATE TABLE fails
because there is a conflicting tables on disk.
Fixed by ensuring that the double free can't happen.
For some reason, in the test main,innodb_ext_key,off
we frequently get unexpected EXPLAIN output, in particular
on Microsoft Windows debug builders. Let us comment out that
EXPLAIN statement for now.
The problem was that opt_sum_query() was, as part of MIN/MAX optimization,
doing read operations on constant tables that where already closed
Fixed by ensuring we don't try to read from tables that are closed.
Starting with commit ef3f71fa74
MemorySanitizer would complain that we are writing uninitialized
data via the doublewrite buffer.
buf_dblwr_t::add_to_batch(): Zero out any unused part of the
doublewrite buffer, for PAGE_COMPRESSED and ROW_FORMAT=COMPRESSED
tables.
Reviewed by: Eugene Kosov
It's a virtual method and it can't be inlined anyway. This allows type
plugins (mysql_json in particular) to use Type_handler_blob and / or
subclass it, without needing to explicitly expose the
vers_type_timestamp object.
Implement a different fix for
"MDEV-19232: Floating point precision / value comparison problem"
Instead of truncating decimal values after every division,
truncate them for comparison purposes.
This reverts commit 62d73df6b2 but keeps the test.
As part of MDEV-23855, we eliminated fil_system.LRU
and changed the way how InnoDB data files are opened.
We are also enforcing the innodb_open_files limit when new
data files are created.
The function fil_space_t::flush() would be invoked by
row_quiesce_table_start(). If the table was already in clean state,
it is possible that the data file is not open.
fil_space_t::flush_low(): If the data file is not open,
check with a debug assertion that there are no unflushed changes,
and carry on.
Reviewed by: Eugene Kosov and Thirunarayanan Balathandayuthapani
In case of direct execution(stmtid=-1, mariadb_stmt_execute_direct in C
API) application is in control of how many parameters client sends to
the server. In case this number is not equal to actual query parameters
number, the server may start to interprete packet data incorrectly, e.g.
starting from the size of null bitmap. And that could cause it to crash
at some point. The commit introduces some additional COM_STMT_EXECUTE
packet sanity checks:
- checking that "types sent" byte is set, and the value is equal to 1.
if it's not direct execution, then that value is 0 or 1.
- checking that parameter type value is a valid type, and parameter
flags value is 0 or only "unsigned" bit is set
- added more checks that read does not go beyond the end of the packet
mariabackup deallocated uninitialized
write_filt_ctxt.u.wf_incremental_ctxt in xtrabackup_copy_datafile() when
some table should be skipped due to parsed DDL redo log record.
If and only if read_variable_length() returns true, the variable
blob_length will be uninitialized and not used. For some reason,
GCC 10.2.0 -Og debug builds would issue a warning.
