Gimp application fails to truncate undo list before adding new undo branch to bottom of list.
Environment/Versions
- GIMP version: 2.99.11 7123b6c4
- Package: flatpak nightly install
- Operating System: Kubuntu Linux 20.04
Description of the bug
A series of operations are performed in a project that results in a number of entries in the Undo list (for example 12) An undo is performed to the 2nd item in the list. An operation is performed and clearly the 3rd to 12th operations in the undo list should be cleared so that the current operation becomes the 3rd operation in the undo list. The clear operation is not taking place, so that the new operation undo step is added to the bottom of an existing list of 12 undo steps, instead of a truncated list of 2 undo steps. The effect of this is to reverse the previous undo action by redoing all of the undone steps in the undo list when the undo list becomes 13 steps long, instead of 3 steps that it should be.
Reproduction
Is the bug reproducible? Always
Reproduction steps:
- Open a project and perform a number of different steps
- Apply an undo over a number of steps of the undo list
- Start a new undo branch by performing a new operation.
…
Expected result: The new undo branch is created by truncating the previous branch in the undo list
Actual result: The new undo branch is created at the bottom of the undo list without truncating the previous branch. This can result in crashes if the new operation for example attempts to work on layers that are removed by the redo operations. An example of such an occurrence was previously documented in #7996 (closed) where the crash resulted from attempting to remove layers that were already removed by the effective redo of steps in the undo list that should have been truncated.
Additional information
These situations have taken place with large multi-layer Gimp projects. The original project being tested at the reporting of bug 7996 was a 233 layer project at the time. It has since grown to 245 layers. The obvious question is whether Gimp has some sort of arbitrary limit on the number of layers that can be handled in a project. There have been no instances of this situation being observed in version 2.99.8 or earlier.