[MDEV-4231] Possible bug in function _ma_apply_undo_row_insert() Created: 2013-03-03  Updated: 2013-05-11  Resolved: 2013-05-11

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 10.0.1, 5.5.30, 5.1.67, 5.2.14, 5.3.12
Fix Version/s: 10.0.3, 5.5.31

Type: Bug Priority: Major
Reporter: Pavel Ivanov Assignee: Michael Widenius
Resolution: Fixed Votes: 0
Labels: 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.



 Comments   
Comment by Michael Widenius [ 2013-05-11 ]

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.

Comment by Michael Widenius [ 2013-05-11 ]

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

Generated at Thu Feb 08 06:54:48 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.