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 /include | |
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 'include')
-rw-r--r-- | include/my_bit.h | 8 |
1 files changed, 8 insertions, 0 deletions
diff --git a/include/my_bit.h b/include/my_bit.h index b19c660d0cd..c7890fa3991 100644 --- a/include/my_bit.h +++ b/include/my_bit.h @@ -122,6 +122,14 @@ static inline uint64 my_set_bits(int n) return (((1ULL << (n - 1)) - 1) << 1) | 1; } +/* Create a mask of the significant bits for the last byte (1,3,7,..255) */ +static inline uchar last_byte_mask(uint bits) +{ + /* Get the number of used bits-1 (0..7) in the last byte */ + unsigned int const used = (bits - 1U) & 7U; + /* Return bitmask for the significant bits */ + return ((2U << used) - 1); +} C_MODE_END #endif /* MY_BIT_INCLUDED */ |