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.

PR sent:

https://github.com/MITK/MITK/pull/189

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.

Thank you! 👍

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:

mitk::UndoController::GetCurrentUndoModel()->SetUndoLimit(100);

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.

Pushed new branch T22774-UndoLimit.