The cause of the crash was that test was setting
aria_sort_buffer_size to MAX_LONG_LONG, which caused an overflow in
my_malloc() when trying to allocate the buffer + 8 bytes.
Fixed by reducing max size of sort_buffer for Aria and MyISAM
Other things:
- Added code in maria_repair_parallell() to not allocate a big sort buffer
for small files.
- Updated size of minumim sort buffer in Aria
The reason for the MDEV reported failures is that the tests are enabling
encryption for Aria but not providing any encryption keys.
Fixed by checking if encryption keys exists before creating the table.
Other things:
- maria.encrypt_wrong-key changed as we now get the error on CREATE
instead during insert.
This patch also fixes some bugs detected by valgrind after this
patch:
- Not enough copy_func elements was allocated by Create_tmp_table() which
causes an memory overwrite in Create_tmp_table::add_fields()
I added an ASSERT() to be able to detect this also without valgrind.
The bug was that TMP_TABLE_PARAM::copy_fields was not correctly set
when calling create_tmp_table().
- Aria::empty_bits is not allocated if there is no varchar/char/blob
fields in the table. Fixed code to take this into account.
This cannot cause any issues as this is just a memory access
into other Aria memory and the content of the memory would not be used.
- Aria::last_key_buff was not allocated big enough. This may have caused
issues with rtrees and ma_extra(HA_EXTRA_REMEMBER_POS) as they
would use the same memory area.
- Aria and MyISAM didn't take extended key parts into account, which
caused problems when copying rec_per_key from engine to sql level.
- Mark asan builds with 'asan' in version strihng to detect these in
not_valgrind_build.inc.
This is needed to not have main.sp-no-valgrind fail with asan.
This patch is the result of running
run-clang-tidy -fix -header-filter=.* -checks='-*,modernize-use-equals-default' .
Code style changes have been done on top. The result of this change
leads to the following improvements:
1. Binary size reduction.
* For a -DBUILD_CONFIG=mysql_release build, the binary size is reduced by
~400kb.
* A raw -DCMAKE_BUILD_TYPE=Release reduces the binary size by ~1.4kb.
2. Compiler can better understand the intent of the code, thus it leads
to more optimization possibilities. Additionally it enabled detecting
unused variables that had an empty default constructor but not marked
so explicitly.
Particular change required following this patch in sql/opt_range.cc
result_keys, an unused template class Bitmap now correctly issues
unused variable warnings.
Setting Bitmap template class constructor to default allows the compiler
to identify that there are no side-effects when instantiating the class.
Previously the compiler could not issue the warning as it assumed Bitmap
class (being a template) would not be performing a NO-OP for its default
constructor. This prevented the "unused variable warning".
If the backup finished in the middle of a Aria bulk load insert,
which could happen with LOAD DATA INFILE, CREATE ... SELECT etc)
there was a chance that Aria recovery would fail on the backup.
Fixed by ensuring that bulk load operations for Aria are not allowed
under BACKUP LOCK.
I also changed so that the table TRN is updated just before truncate
which ensures that old redo's for the table are ignored.
I also enabled Aria redo for DDL's to be able to repeat REPAIR commands.
Without this change recovery would not work on repaired tables.
Notes:
- We take the backup lock protection at the end of bulk insert (as we
don't want to keep the lock over a very long running insert).
If mariadb-backup keeps the backup lock too long, this may fail with
a lock timeout. In this case the batch insert will fail and the table
will be truncated (set to it's original state).
This could happen if one did a DML with a moved table that one had done
an external zerofill on.
The crash happend because a message that was supposed to be sent to
a repair report was instead sent to the result, which caused an ASSERT
To prevent ASAN heap-use-after-poison in the MDEV-16549 part of
./mtr --repeat=6 main.derived
the initialization of Name_resolution_context was cleaned up.
In commit 28325b0863
a compile-time option was introduced to disable the macros
DBUG_ENTER and DBUG_RETURN or DBUG_VOID_RETURN.
The parameter name WITH_DBUG_TRACE would hint that it also
covers DBUG_PRINT statements. Let us do that: WITH_DBUG_TRACE=OFF
shall disable DBUG_PRINT() as well.
A few InnoDB recovery tests used to check that some output from
DBUG_PRINT("ib_log", ...) is present. We can live without those checks.
Reviewed by: Vladislav Vaintroub
This patch fixes the following issues in Aria error reporting in case
of read errors & crashed tables:
- Added the table name to the most error messages, including in case of
read errors or when encrypting/decrypting a table. The format for
error messages was changed sligtly to accomodate logging of errors
from lower level routines.
- If we got an read error from storage (hard disk, ssd, S3 etc) we only
reported 'table is crashed'. Now the error number from the storage
is reported.
- Added checking of read failure from records_in_range()
- Calls to ma_set_fatal_error() did not inform the SQL level of
errors (to not spam the user with multiple error messages).
Now the first error message and any fatal error messages are reported
to the user.
Reading the last page of table with "dynamic page" format would generate
an error when reading after the last row. This was never noticed as
when using Aria as a handler any error messages generated by
_ma_set_fatal_error() was ignored.
If we got a read error from S3, we did not signal threads waiting
to read blocks in the read-range. This caused these threads to
hang forever.
There is still one issue left that the S3 error will be logged as an
'table is crashed' error instead of the IO error. This will be fixed
by a larger patch in 10.6 that improves error reporting from Aria.
There is no test case for this as it is very hard to repeat.
I tested this with a patch that causes random read failures in S3
used perl multi-threaded test with 8 threads to simulate reads.
This patch fixes all found hangs.
- Fixed wrong DBUG_ASSERT when waiting for big-block-read
- Update S3_pagecache_reads counter when reading a block from S3.
Before this patch the variable value was always 0
Reviewer: Oleksandr Byelkin <sanja@mariadb.com>
The assert happens in 10.6 with the following command:
./mtr --no-reorder --verbose-restart main.update_ignore_216 main.upgrade_MDEV-19650 main.upgrade_MDEV-23102-1 main.upgrade_MDEV-23102-2 main.upgrade_geometrycolumn_procedure_definer main.upgrade_mdev_24363 main.varbinary sys_vars.aria_log_file_size_basic
Reviewer: Oleksandr Byelkin <sanja@mariadb.com>