This report quite similar (or very closely related) to bug 152799, except few additional steps being needed to triggering the crash.

Assigning to myself because I have a preliminary fix. I'll try to get a more thorough explanation and a patch up in <24 hours from this comment.

It is indeed very closely related to bug 152799, and my fix should cover both.

WIP fix for a single layer of grouping here: https://gerrit.libreoffice.org/c/core/+/186251

I'm still working on fixing it for multiple layers of nested groups. I think that I know how to do that; the code currently assumes that all textboxes are either on the group or one of its immediate children, but in fact textboxes can be on any descendant of the group draw object. SwDoc::UnGroupSelection gets this right but the undo/redo functions currently do not.

Here is a simple way to reproduce the issue from a new document:

1. Create a first shape using: Insert > Shape > Basic Shapes > Rectangle
2. Create a second shape using: Insert > Shape > Basic Shapes > Rectangle
3. (Select and right click the first shape) > Add Text Box
4. Optionally, insert some text into the text box.
5. Select both rectangles and then group them using: Format > Group Shapes > Group
6. Immediately ungroup them using: Format > Group Shapes > Ungroup.
7. Undo.

The key situation here is undo/redo with groups containing "Text Boxes". In Writer, a Text Box is a bit of arbitrary Writer content that is paired with a Draw object in the Draw pane of the Writer document. They were added to improve compatibility with Microsoft Office formats.

I wish that the fix were simple, but unfortunately this wasn't a single-line fix. Broadly speaking, there were issues with how the undo classes `SwUndoDrawGroup` and `SwUndoDrawUnGroup` managed the ownership and lifetimes of the text boxes, and I just had to iteratively debug/fix the issues until it worked.

This bug report was about ungrouping, but in fact there were very similar issues with grouping that also needed to be fixed.

Concretely, the two undo classes own (i.e are responsible for deleting) `SwFrameFormat`s, which are the part of the text box that holds the Writer content. There are `SwFrameFormat`s for both the individual members of the group and the group itself. Which ones the undo classes own (versus the document owning) depends on the current state of the document:

1. If the document is in a state where the members are currently grouped, then the undo class owns the `SwFrameFormat`s for the individual members, because those `SwFrameFormat`s are not currently attached to the document.
2. If the document is in a state where the members are currently ungrouped, then the undo class owns the `SwFrameFormat` for the group, because that `SwFrameFormat` is not currently attached to the document.

Note that this means that a "done group operation", "undone ungroup operation", and "redone group operations" are all similar to each other (the undo class owns the individual frames), and likewise a "done ungroup operation", "undone group operation", and "redone ungroup operation" are all similar to each other (the undo class owns the group frame).

The value of the boolean `m_bDeleteFormat` tells you which state the undo class is in.

The undo classes do not directly own the `SwTextBoxNode`s. Instead, the `SwFrameFormat`s collectively own the `SwTextBoxNode`s through shared pointers. The `SwTextBoxNode`s also have a link back to every `SwFrameFormat` that owns them. There is an asymmetry in the frames. One `SwFrameFormat` is the parent and the rest are the children.

When I was debugging issues with group/ungroup redo/undo, LibreOffice always told me that I wasn't done yet in one of two ways:

1. SwTextBoxNode::~SwTextBoxNode(): Assertion `false' failed.
2. An issue inside of SwUndoDelLayFormat::SwUndoDelLayFormat

The meaning of (1) is that an `SwTextBoxNode` is surprised that it is being deleted while it still has back links to `SwFrameFormat`s.
The meaning of (2) is that an `SwTextBoxNode` has had `ClearAll()` called on it and is trying to cause its children `SwFrameFormat`s to delete themselves and remove themselves from its member list, but they aren't deleting themselves because they are used elsewhere.

Both of these happen because `SwTextBoxNode` believes that it "owns" the children frames within it. And it does, normally, outside of the undo/redo context. But in the undo/redo context, the undo classes own the frames.

So one guiding principle of the fix is that the `SwFrameFormat`s that the undo classes own (which, again, depends on the state) should never have non-empty `SwTextBoxNode`s, because `SwTextBoxNode`s don't know how to deal with the situation of having children that they aren't responsible for deleting.

There is one more important thing to understand: in a given group, there is exactly one `SwTextBoxNode`, and no matter how many layers of nested groups there are, all of the `SwFrameFormat`s are held as direct children of that one `SwTextBoxNode`. This means that ungrouping the group involves doing a tree traversal (depth-first search) to figure out how to partition the `SwFrameFormat`s among the new `SwTextBoxNode`s that are created for the newly independent children of the former group.

So the other guiding principle of the fix is that the undo classes have to do DFS whenever moving from a state where the members are currently grouped to a state where the members are currently ungrouped. We can't avoid the DFS by having the member frames contain non-empty `SwTextBoxNode`s because, remember, `SwTextBoxNode`s don't know how to have children that they aren't responsible for deleting.

Fixes are here:
1. For non-nested groups: https://gerrit.libreoffice.org/c/core/+/186251
2. For nested groups: https://gerrit.libreoffice.org/c/core/+/186393