https://bugs.documentfoundation.org/show_bug.cgi?id=99619
Neil Roberts <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #16 from Neil Roberts <[email protected]> --- I think what is happening is this: Internally, the join is called a connection and is stored in an OQueryTableConnection. When a connection is added an OQueryAddTabConnUndoAction is created to record the undo action. When the action is undone, OQueryAddTabConnUndoAction calls OQueryTableView::DropConnection which calls OQueryTableView::RemoveConnection. That in turn tries to add another undo action to allow undoing the remove. This second undo object is marked as “owning” the OQueryTableConnection. The second undo object is blocked from being added to the undo manager because SfxUndoManager::mbUndoEnabled is set to false while an undo operation is taking place. When the undo operation is finished being applied this second undo operation is instead immediately deleted. However, because it thinks it owns the OQueryTableConnection it calls dispose on it which makes it no longer have a window pointer. The first undo operation then marks itself as owning the connection. When the redo button is pressed, the “add connection” operation is redone but it crashes when it tries to access the null window pointer. You can also trigger the bug if you delete the join with the delete key and then press undo, redo, undo. I made a UI test case to trigger the bug and I’m trying to think of the best way to fix it. -- You are receiving this mail because: You are the assignee for the bug.
