1) Select Freehand tool
2) Do several strokes and pay attention to how the actions are added to the list
There are three ways how it works:
1) The new item appears in the list with the proper item
2) The new item appears without any icon (it's size is smaller than the size of other items). In a couple of seconds the icon is generated and the size is changed.
3) The new item appears without the icon and no icon is generated until you move your mouse pointer to the item.
I think there is some race condition in the process of the generation of items. I guess, the generation of the preview with the delay is not bad in general, but the item should not change it's size at least. And the 3rd case is surely a bug.
There is one more bug possible:
The point is the thumbnail is requested from the image on arrival of a signal from the undo stack. Such signal usually comes when the some code calls to undoAdapter->endMacro(). The trouble is that undoAdapter->endMacro() is always called *before* calling setDirty(). It means that requesting the image on QUndoStack::indexChanged() will always generate wrong thumbnail. In most of the cases now, I guess, some timer delay hides this problem, so the bug is not seen usually. But there are cases when it can bee seen.
There was a bug  (though it had a different nature), but it appeared due to this behavior of the KisUndoModel.
 - https://bugs.kde.org/show_bug.cgi?id=290563
To me, this now actually looks correct, when painting. Could this have been fixed after merging the strokes stuff?
Hm... I don't seen any icons anymore in the undo docker, though the images are still being generated. I think we shouldn't do previews here, but use the tool icons, like Photoshop CS 2.
Git commit 7550692bc5747c5c946f94f8d35ce23bbf19e42a by Boudewijn Rempt.
Committed on 30/01/2015 at 10:41.
Pushed by rempt into branch 'calligra/2.9'.
Restore the undo docker preview images
M +4 -2 krita/plugins/extensions/dockers/historydocker/KisUndoModel.cpp
Seems to be fixed now