Page MenuHomePhabricator

crash because unlimited undo history
Closed, ResolvedPublic


The application crashes or gets killed by the kernel if you are doing a long running segmentation. It means 30-60 minutes.

It probably happens because the current undo models do not set a limit on the length of the undo history, just keep adding operations until you clean the whole stack.


I used 2015.05.2. It is very likely reproducable with the master as well. The relevant code (undo controller and undo models) has not changed.

Steps to reproduce:

Start using the draw tool and check with "top" in a terminal window how the used memory grows. After a long time this would make the application crash.

We saw crashes like this with the MITK segmentation plugin, and also with our segmentation plugin that uses a different draw tool, but the same undo/redo framework.

Revisions and Commits

Event Timeline

The fix is probably easy. There are several ways.

In principle, you can replace the undo model of the undo controller. You can also derive your undo model class from the current ones to introduce a limit.

However, the set of supported undo model types is hard coded in the undo controller class. So, even if you define your undo model that drops the bottom of the stack, you cannot plug it in.

So, instead of this, I would suggest to add a new function to mitk::LimitedLinearUndo to set the depth of the undo stack. The SetOperationEvent function should drop the old operations if the stack size limit is reached.

I can send a pull request.

kislinsk triaged this task as Normal priority.Apr 27 2017, 9:34 AM
kislinsk added a subscriber: kislinsk.

+1 for the mitk::LimitedLinearUndo extension. Would be nice to have a setting in the preferences for the depth of the undo stack. An approach based on used RAM would be nice as well but that's probably something for later.

PR sent:

This allows setting an undo limit, but leaves the default unlimited.

Not sure if we can find an estimate based on used RAM. The limit is in terms of number of items on the undo stack, but you cannot tell how big the items are. Also, there is just one undo controller, but different plugins can put items on the stack of very different size.

Note that I could not compile the PR because of T22775, but I tried it on 2015.05.2.

I updated the PR because the limit was applied only in one of the undo models. (The verbose undo model overrode the function in which the superclass applied the limit.)

It is working well now.

I put the call for the new SetUndoLimit() function into the activator of our application plugin. Since the undo controller is global, it should fix the crash in both segmentation plugins (MITK and ours) in our applications. The call is:


So, the PR is complete, but you probably also want to set the limit also for your applications, e.g. MitkWorkbench. Or change the default limit from 0 to something else.

kislinsk added a revision: Restricted Differential Revision.Mar 6 2018, 11:25 AM
kislinsk claimed this task.