Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-3901

Corruption of operation tracking log files

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 3.6.4, 3.7.3, WT3.1.0
    • Affects Version/s: None
    • Component/s: None
    • None
    • Storage 2018-02-12

      Flushing the operation tracking memory buffer to the file works as follows:

      1. We remember the old value of the file offset.
      2. We flush the buffer, opening the file if it has not been open yet.
      3. We add the return value to the remembered offset.

      The problem occurs in the situation when we flush to a file that has not been open yet. Here is what happens:

      1. We remember the old value. It is 0, because the file has not been opened yet.
      2. As we flush the buffer, the file is opened. BUT: opening the file writes some metadata to it and advances the offset to 12. We flush the buffer at offset 12. We return the number of bytes flushed.

      Upon return we should add the number of bytes flushed to 12, the previous offset, but:

      3. We add the returned value (number of bytes flushed) to the remembered offset, which was 0!

      So the offset is now incorrect. Next time we flush the buffer, we corrupt the data.

            sasha.fedorova@mongodb.com Sasha Fedorova
            sasha.fedorova@mongodb.com Sasha Fedorova
            0 Vote for this issue
            3 Start watching this issue