Repro
Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 4659fc2f0a7223a89446edff0b77e58758b5edf5
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: en-US (nl_NL); UI: en-US
Calc: CL Jumbo

Created attachment 179705 [details]
bt with debug symbols

I got an assertion on pc Debian x86-64 with master sources updated today.

Considering the number of crashes due to undo, I'm not sure it worths it to keep on testing undoing for the moment.

Looks like bug 147726 (for the assert part)

Other undo bugs are mostly regressions, this one is InNherited. 
Also, unlike some bugs with "copy 5x, paste 3x.." this one is simple copy+paste.

A mystery for me is why there are 266 crash reports for LO 7.3 Win when I see this crash all the way to OO including Lin.

Repro with recent debug build:

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 1b463f697405e64a03378fb38a32172c4d3c25e6
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

Getting the same assert:

warn:legacy.osl:389415:389415:sw/source/core/access/accmap.cxx:1074: invalid event combination
soffice.bin: /home/tdf/lode/jenkins/workspace/lo_gerrit/tb/src_master/sw/source/core/undo/undel.cxx:915: virtual void SwUndoDelete::UndoImpl(sw::UndoRedoContext&): Assertion `pTextNd' failed.

In 7.5.2.2 (not debug), I get this crash report: https://crashreport.libreoffice.org/stats/crash_details/8ffc1cee-0081-4dc4-a92d-b55fcf3ebc12

With the extra signature "BigPtrArray::Index2Block(int) const".

Yep, followed comment 0 exactly.

CRASH:

- https://crashreport.libreoffice.org/stats/crash_details/67812785-33aa-434c-b7c5-12dd5941ca3b

in:

Version: 24.2.0.3 (X86_64) / LibreOffice Community
Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1
CPU threads: 8; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded

Still crashing in:

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: bdf3b5ce49b0e4ee1b4525d344cfb037ef473059
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL threaded

I think that I understand what's going on here.

Reproduction from empty documents:

1. Create a new document.
2. View > Styles. Click the "page styles" icon in the styles pane.
3. Right click an item and choose "new".
4. Apply, then OK.
5. Double click the newly created style in the styles pane to apply it.
6. Create a footer.
7. Insert some text into the footer (optional, but makes it clearer that the footer is copied).
8. Enter at least two paragraphs (or more generally nodes) in the main body of the first document.
9. Create a second new document.
10. Enter some text in the main body of the second document.
11. Ctrl-A then Ctrl-C in the first document.
12. Ctrl-A then Ctrl-V in the second document.
13. Ctrl-Z in the second document.

The source document must 1) have a non-default page style applied, and 2) have a header and/or footer. The selection from the source document must also 3) include at least two nodes. There also must 4) be a non-empty selection in the destination document that is overwritten by the copy/paste, and 5) the destination document can't already contain a page style with the same name as the non-default page style from the source document selection.

When these conditions are met, the copy will include the header and/or footer from the source document.

(See here, where the page desc, which exists if there is a page style applied, is copied, which also copies the header/footer: https://opengrok.libreoffice.org/xref/core/sw/source/core/attr/swatrset.cxx?r=ac3b217a43e21b00f434fa796a0c966b9ddfd9df#423 )

Pasting into the destination document is a two stage process, and then undoing the paste is another two stage process:

1. Pasting into the destination document.
   a. Deleting the selection.
   b. Inserting the pasted content.
2. Undoing the paste.
   a. Deleting the pasted content.
   b. Re-inserting the selection.

In step 1a, the undo information saves the index from the document SwNodes where it will re-insert the selection later.

(There's a comment about how undo information stores document indices here: https://opengrok.libreoffice.org/xref/core/sw/source/core/undo/untblk.cxx?r=ac3b217a43e21b00f434fa796a0c966b9ddfd9df#239 )

By step 2b, something is wrong. The header/footer nodes are still in the document, and it messes up the indexing, so the re-insertion point, which should've been a text node, is actually a start node, which causes the cryptic error.

The solution is to modify SwDoc::CopyPageDescHeaderFooterImpl to record the copying of the header/footer nodes so that they are correctly undone and don't mess up the indexing.

I am working on a small fix and regression test.

Created attachment 200968 [details]
gdb session with destination document SwNodes

I've attached some snippets from my gdb session showing the contents of the destination document SwNodes after steps 1a, 1b, and 2a.

The problem is that the first and the third versions look different, even though the logical difference between them is inserting the pasted text and then removing it. The re-insertion point for the deleted selection was recorded as 9, but now that point has shifted to 12 because of the extra 3 nodes representing the leftover footer.

Created attachment 200969 [details]
simple reproduction

I've done steps 1-10 from my previous comment in the two .odt attachments for a simpler reproduction.

Fix is here: https://gerrit.libreoffice.org/c/core/+/185940