Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-35253

innodb.xa_prepare_unlock_unmodified fails in UBSAN

Details

    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

          Ascending order - Click to sort in descending order
          sanja Oleksandr Byelkin created issue -
          sanja Oleksandr Byelkin made changes -
          Field Original Value New Value
          Assignee Oleksandr Byelkin [ sanja ] Sergei Petrunia [ psergey ]
          marko Marko Mäkelä made changes -
          Summary innodb.xa_prepare_unlock_unmodified fails in ASAN innodb.xa_prepare_unlock_unmodified fails in UBSAN
          psergei Sergei Petrunia made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          psergei Sergei Petrunia added a comment -

          So, the problem happens here:

                  const key_part_map all_key_parts= PREV_BITS(uint, key_parts);

          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.

          psergei Sergei Petrunia added a comment - So, the problem happens here: const key_part_map all_key_parts= PREV_BITS(uint, key_parts); 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.
          psergei Sergei Petrunia added a comment - 

          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.

          psergei Sergei Petrunia added a comment - 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.
          sanja Oleksandr Byelkin added a comment -

          OK to push but in 10.5 and with the test case please.

          sanja Oleksandr Byelkin added a comment - OK to push but in 10.5 and with the test case please.
          psergei Sergei Petrunia made changes -
          Fix Version/s 10.5.27 [ 29902 ]
          Fix Version/s 10.6.20 [ 29903 ]
          Fix Version/s 10.11.10 [ 29904 ]
          Fix Version/s 11.2.6 [ 29906 ]
          Fix Version/s 11.4.4 [ 29907 ]
          Fix Version/s 11.6.2 [ 29908 ]
          Fix Version/s 10.6 [ 24028 ]
          Resolution Fixed [ 1 ]
          Status In Progress [ 3 ] Closed [ 6 ]

          People

            psergei Sergei Petrunia
            sanja Oleksandr Byelkin
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.