diff options
| author | Vladislav Vaintroub <wlad@mariadb.com> | 2019-05-09 17:38:22 +0200 |
|---|---|---|
| committer | Vladislav Vaintroub <wlad@mariadb.com> | 2019-05-09 18:58:16 +0200 |
| commit | ad36d38024cf82724f5e9589fc9fe4ad57fcf390 (patch) | |
| tree | c4921ca39005b5709ff1287f086de708ddd8f5ad /sql/mysqld.h | |
| parent | 44b8b002f56d5d0c5da3d600276965c41d9ab7bf (diff) | |
| download | mariadb-git-ad36d38024cf82724f5e9589fc9fe4ad57fcf390.tar.gz | |
MDEV-19235 MariaDB Server compiled for 128 Indexes crashes at startupbb-10.4-wlad-MDEV-19235
With MAX_INDEXIES=64(default), key_map=Bitmap<64> is just a wrapper around
ulonglong and thus "trivial" (can be bzero-ed, or memcpy-ed, and stays
valid still)
With MAX_INDEXES=128, key_map = Bitmap<128> is not a "trivial" type
anymore. The implementation uses MY_BITMAP, and MY_BITMAP contains pointers
which make Bitmap invalid, when it is memcpy-ed/bzero-ed.
The problem in 10.4 is that there are many new key_map members, inside TABLE
or KEY, and those are often memcopied and bzeroed
The fix makes Bitmap "trivial", by inlining most of MY_BITMAP functionality.
pointers/heap allocations are not used anymore.
Diffstat (limited to 'sql/mysqld.h')
| -rw-r--r-- | sql/mysqld.h | 10 |
1 files changed, 1 insertions, 9 deletions
diff --git a/sql/mysqld.h b/sql/mysqld.h index b8c6e5f79bb..ddb3f23bcd0 100644 --- a/sql/mysqld.h +++ b/sql/mysqld.h @@ -41,15 +41,7 @@ struct scheduler_functions; typedef struct st_mysql_show_var SHOW_VAR; -#if MAX_INDEXES <= 64 -typedef Bitmap<64> key_map; /* Used for finding keys */ -#elif MAX_INDEXES > 128 -#error "MAX_INDEXES values greater than 128 is not supported." -#else -typedef Bitmap<((MAX_INDEXES+7)/8*8)> key_map; /* Used for finding keys */ -#endif - - /* Bits from testflag */ +/* Bits from testflag */ #define TEST_PRINT_CACHED_TABLES 1U #define TEST_NO_KEY_GROUP 2U #define TEST_MIT_THREAD 4U |