Details
Critical Description
innodb.xa_prepare_unlock_unmodified w2 [ fail ] Found warnings/errors in server log file!
|
Test ended at 2024-10-23 14:55:54
|
line
|
/home/buildbot/buildbot/build/mariadb-10.6.20/sql/sql_select.cc:8289:43: runtime error: shift exponent 32 is too large for 32-bit type 'unsigned int'
|
^ Found warnings in /dev/shm/var/2/log/mysqld.1.err
|
ok
|
|
|
- saving '/dev/shm/var/2/log/innodb.xa_prepare_unlock_unmodified/' to '/dev/shm/var/log/innodb.xa_prepare_unlock_unmodified/'
|
|
|
Retrying test innodb.xa_prepare_unlock_unmodified, attempt(2/2)...
|
Attachments
Activity
commit d8445ddfad233f00bd0b924e4283fa79acae0e6a (HEAD -> bb-10.6-MDEV-32253, origin/bb-10.6-MDEV-32253, bb-10.6-release, bb-10.6-mdev32253)
|
Author: Sergei Petrunia <sergey@mariadb.com>
|
Date: Fri Oct 25 15:33:57 2024 +0300
|
|
|
MDEV-35253: xa_prepare_unlock_unmodified fails: shift exponent 32 is too large
|
|
The code in best_access_path() uses PREV_BITS(uint, N) to
|
compute a bitmap of all keyparts: {keypart0, ... keypart{N-1}).
|
|
The problem is that PREV_BITS($type, N) macro code can't handle the case
|
when N=<number of bits in $type).
|
Also, why use PREV_BITS(uint, ...) for key part map computations when
|
we could have used PREV_BITS(key_part_map) ?
|
|
Fixed both:
|
- Change PREV_BITS(type, N) to handle any N in [0; n_bits(type)].
|
- Change PREV_BITS() to use key_part_map when computing key_part_map bitmaps.
|
So, the problem happens here:
sizeof(uint)=4 , PREV_BITS is defined as:
#define PREV_BITS(type,A) ((type) (((type) 1 << (A)) -1))so we try to compute 1<<32 which is undefined.
Two issues here:
1. Why are we using PREV_BITS(uint, ... )? sizeof(key_part_map)=8, while MAX_REF_PART=32 , so we can easily side-step the problem by using PREV_BITS(key_part_map).
2. The fact that PREV_BITS(uint, 32) doesn't work is a gotcha that we shouldn't have.