summaryrefslogtreecommitdiff
path: root/mysys
diff options
context:
space:
mode:
authorVladislav Vaintroub <wlad@mariadb.com>2019-05-09 17:38:22 +0200
committerVladislav Vaintroub <wlad@mariadb.com>2019-05-09 18:58:16 +0200
commitad36d38024cf82724f5e9589fc9fe4ad57fcf390 (patch)
treec4921ca39005b5709ff1287f086de708ddd8f5ad /mysys
parent44b8b002f56d5d0c5da3d600276965c41d9ab7bf (diff)
downloadmariadb-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 'mysys')
-rw-r--r--mysys/my_bitmap.c11
1 files changed, 0 insertions, 11 deletions
diff --git a/mysys/my_bitmap.c b/mysys/my_bitmap.c
index 4db6b8a44f8..24653fd301f 100644
--- a/mysys/my_bitmap.c
+++ b/mysys/my_bitmap.c
@@ -38,17 +38,6 @@
#include <m_string.h>
#include <my_bit.h>
-
-/* 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);
-}
-
/*
Create a mask with the upper 'unused' bits set and the lower 'used'
bits clear. The bits within each byte is stored in big-endian order.