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

Possible bug in function _ma_apply_undo_row_insert()

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 10.0.1, 5.5.30, 5.1.67, 5.2.14, 5.3.12
    • 10.0.3, 5.5.31
    • None
    • None

    Description

      Function _ma_apply_undo_row_insert() (starts at line 6887 of storage/maria/ma_blockrec.c) doesn't look right. All through the function if some error condition happens it jumps to the 'err' label, but from there it jumps back to the 'end' label. And here first it calls _ma_bitmap_flushable(info, -1) which seems to be necessary only after the call to _ma_bitmap_flushable(info, 1). But jump to the 'err' label can happen before that call.
      And second at the 'end' label it calls _ma_unpin_all_pages_and_finalize_row(info, lsn). But variable 'lsn' gets initialized only after 4 possible jumps to the 'err' label and I don't see a possible path inside _ma_unpin_all_pages_and_finalize_row that won't use contents of 'lsn' variable.

      All this doesn't look right and needs some fixing.

      Attachments

        Activity

          The code is:
          end:
          if (info->non_flushable_state)
          _ma_bitmap_flushable(info, -1);

          The variable non_flushable_state is true if and only if we called _ma_bitmap_flushable(info, 1) before in this function.
          So it means that the code is correct when it comes to the first point.
          I will however add a comment about this.

          The second case is a kind of a bug. It doesn't matter that LSN is a wrong number as we are marking the table as crashed. However, to make things predictable it's better to use a known LSN here.

          Thanks a lot for looking and trying to understand the code.

          monty Michael Widenius added a comment - The code is: end: if (info->non_flushable_state) _ma_bitmap_flushable(info, -1); The variable non_flushable_state is true if and only if we called _ma_bitmap_flushable(info, 1) before in this function. So it means that the code is correct when it comes to the first point. I will however add a comment about this. The second case is a kind of a bug. It doesn't matter that LSN is a wrong number as we are marking the table as crashed. However, to make things predictable it's better to use a known LSN here. Thanks a lot for looking and trying to understand the code.

          Fixed in my 5.5 code repository. Will be pushed together with other fixes later today.

          monty Michael Widenius added a comment - Fixed in my 5.5 code repository. Will be pushed together with other fixes later today.

          People

            monty Michael Widenius
            pivanof Pavel Ivanov
            Votes:
            0 Vote for this issue
            Watchers:
            3 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.