Bug 94225 - Writer crashes on undo times N (steps in Comment 11 or Comment 38)
Summary: Writer crashes on undo times N (steps in Comment 11 or Comment 38)
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: highest critical
Assignee: Fyodor
URL:
Whiteboard: target:6.1.0 target:6.0.1
Keywords: haveBacktrace
: 107973 (view as bug list)
Depends on:
Blocks: Undo-Redo
  Show dependency treegraph
 
Reported: 2015-09-15 06:32 UTC by Stefan
Modified: 2018-01-29 13:17 UTC (History)
17 users (show)

See Also:
Crash report or crash signature: ["SwNoTextFrame::HasAnimation()"]


Attachments
Backtrace of crash on Windows (11.55 KB, text/plain)
2015-09-21 09:57 UTC, Buovjaga
Details
Reproducer file (27.44 KB, application/vnd.oasis.opendocument.text)
2015-10-02 13:35 UTC, Matthew Francis
Details
gdb on core file on linux (56.91 KB, text/plain)
2015-10-02 16:49 UTC, Terrence Enger
Details
backtraces compared, Win vs. Linux (15.34 KB, application/vnd.oasis.opendocument.spreadsheet)
2015-10-02 18:51 UTC, Terrence Enger
Details
console bt logs (10.55 KB, text/plain)
2016-05-27 13:35 UTC, Julien Nabet
Details
DrMemory logs.zip (402.92 KB, application/binary)
2016-10-07 17:35 UTC, Timur
Details
Valgrind trace (26.24 KB, application/x-bzip)
2016-10-07 21:21 UTC, Julien Nabet
Details
bt with debug symbols (9.22 KB, text/plain)
2017-05-20 06:01 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan 2015-09-15 06:32:44 UTC
1.) new document
2.) insert a paragraph with text
3.) insert an empty paragraf
4.) insert a paragraph with text
5.) insert an image to the empty paragraph
6.) mark all and copy
7.) insert the clipboard copy sometimes (at the end of document)
8.) Crtl-z (sometimes)
9.) -> Fatal Error
Comment 1 Buovjaga 2015-09-19 16:01:56 UTC
Could not reproduce.

Win 7 Pro 64-bit, Version: 5.0.1.2 (32-bit)
Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261
Locale: fi-FI (fi_FI)
Comment 2 Yousuf Philips (jay) (retired) 2015-09-20 14:55:00 UTC
Hi Stefan,

Thanks for reporting the bug. Can you provide a document which reproduces this error and is fill up to step 5, so we can continue with the next steps? Which operating system are you running on?

Wasnt able to reproduce either.

Version: 5.1.0.0.alpha1+
Build ID: cbf3fac0a5a1be34b2e1a58da959debd24ebc017
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-09-17_07:03:22
Locale: en-US (en_US.UTF-8)
Comment 3 Stefan 2015-09-21 09:28:44 UTC
i confirmed this behavior with my (re)installed 4.4.5.2. too. (win7 64bit/En-US LO en-us too)

Yousuf (Jay) Philips, I can't provide a document with "filled" clipboard or Undo-Stack :/

So try this:

1.) new document
2.) insert a paragraph with text ("Asdadad asd asd asda da dasda da" <- don't copy from here!)
3.) insert an empty paragraf (so use your return-key)
4.) insert a paragraph with text (do it like (1.) )
5.) insert an image to the empty paragraph (menu->insert->image, not as link, default)
6.) mark all and copy (set cursor at the beginning, hold shift and click after the last character)
7.) click after the last charcter (removes "selection")
8.) insert the clipboard 10 times (ctrl-v, ctrl-v, ctrl-v ....)
9.) undo 11 times (ctrl-z, ctrl-z, ctrl-z, ctrl-z ...)
10.) -> Fatal Error

I hope this helps to reproduce.
Comment 4 Buovjaga 2015-09-21 09:57:33 UTC
Created attachment 118894 [details]
Backtrace of crash on Windows

Thanks, now I was able to repro. Took more undo steps than 11, though. More like 15.

Win 7 Pro 64-bit, Version: 5.0.1.2 (32-bit)
Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261
Locale: fi-FI (fi_FI)
Comment 5 raal 2015-10-01 14:27:20 UTC
I can reproduce  with  Version: 5.1.0.0.alpha1+ (x64)
Build ID: 09fc6fef2d03ca8558dd6f0eec45d61ceb282cb5
TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2015-09-27_22:33:48
Comment 6 Robinson Tryon (qubit) 2015-10-01 14:34:41 UTC
TESTING with Ubuntu 14.04 +
Version: 5.1.0.0.alpha1+
Build ID: 6e8e898acb9f6825104f01d090f447e8dfc7e4a2
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-10-01_05:44:30
Locale: en-US (en_US.UTF-8)

(In reply to Stefan from comment #3)
> So try this:
> 
> 1.) new document
> 2.) insert a paragraph with text ("Asdadad asd asd asda da dasda da" <-
> don't copy from here!)
> 3.) insert an empty paragraf (so use your return-key)
> 4.) insert a paragraph with text (do it like (1.) )
> 5.) insert an image to the empty paragraph (menu->insert->image, not as
> link, default)
> 6.) mark all and copy (set cursor at the beginning, hold shift and click
> after the last character)

Do you then use Ctrl-c to copy?
(Wasn't mentioned explicitly, so I'm assuming that step is also done)

> 7.) click after the last charcter (removes "selection")
> 8.) insert the clipboard 10 times (ctrl-v, ctrl-v, ctrl-v ....)
> 9.) undo 11 times (ctrl-z, ctrl-z, ctrl-z, ctrl-z ...)
> 10.) -> Fatal Error

No crash, so NO REPRO from me.

(Also unable to reproduce with 5.0.1.2 on same Ubuntu 14.04 system)

Sefan: Can you reproduce this bug with a build of master? You can get a daily build here:
http://dev-builds.libreoffice.org/daily/master/
Comment 7 Robinson Tryon (qubit) 2015-10-01 14:36:52 UTC
(In reply to Robinson Tryon (qubit) from comment #6)
> No crash, so NO REPRO from me.
> 
> (Also unable to reproduce with 5.0.1.2 on same Ubuntu 14.04 system)

Per Raal's repro (and my lack of repro), I'm going to change
OS -> Windows
Comment 8 Matthew Francis 2015-10-01 14:56:08 UTC
Reproduced on Linux (Ubuntu 14.04)

Bibisect daily dbgutil repo,
2015-09-18: source-hash-9ce08dcc2e32c5554ddf71b79173f8854e0568ad

Setting OS back to All
Comment 9 Terrence Enger 2015-10-01 15:55:53 UTC
Looking at the mixture of crash and no-crash comments, I wonder if the
program behaviour is dependent on the type of image inserted, or even
upon something in how that imaged is formed.  It would be nice if
somebody would attach a crash-provoking image file.  Even nicer would
be 4 image files: crash-provoking and not, and from tests on Windows
and Linux.

Terry.
Comment 10 Buovjaga 2015-10-01 16:23:49 UTC
(In reply to Robinson Tryon (qubit) from comment #6)
> > 7.) click after the last charcter (removes "selection")
> > 8.) insert the clipboard 10 times (ctrl-v, ctrl-v, ctrl-v ....)
> > 9.) undo 11 times (ctrl-z, ctrl-z, ctrl-z, ctrl-z ...)
> > 10.) -> Fatal Error
> 
> No crash, so NO REPRO from me.

Did you undo about 15 times like I did?
Comment 11 Matthew Francis 2015-10-02 13:35:10 UTC
Created attachment 119202 [details]
Reproducer file

I can reliably reproduce on Linux with the attached file back to the year dot

Steps
1. Load the file
2. Select all (Ctrl+A)
3. Copy (Ctrl+C)
4. Paste (Ctrl+V) times N
5. Undo (Ctrl+Z) times at least N

For current builds from the 5.1 daily dbgutil repo, N is 1
For OOo 3.3.0 and other intermediate releases, N may be up to 15
Comment 12 Terrence Enger 2015-10-02 16:49:47 UTC
Created attachment 119207 [details]
gdb on core file on linux

Note that my failure is SIGABRT; the Windows backtrace in comment 11
shows an ACCESS VIOLATION.

'Backtrace' is at line 59, 'backtrace full' at line 124.

As I followed the steps in comment 11, the crash occurred at step 5
with N=1.  Note that step 3 does not remove the selection, so step 4
replaces the content of the document with a copy of itself; the only
visible result is unmarking the selection.  I wonder if this was what
Matthew intended?

This observation is from master commit f78216d, fetched 2015-09-21
02:45 UTC, configured ...
    CC=ccache /home/terry/lo_hacking/associated/gcc/bin/gcc
    CXX=ccache /home/terry/lo_hacking/associated/gcc/bin/g++
    --enable-option-checking=fatal --enable-dbgutil --enable-crashdump
    --without-system-postgresql --without-myspell-dicts
    --with-extra-buildid --without-doxygen
    --with-external-tar=/home/terry/lo_hacking/git/src
    --disable-gstreamer-1-0 --enable-gstreamer-0-10 --disable-gtk3
built on debian-wheezy with local-built gcc 5.2.0 and its system
libraries, running chroot'd to debian-sid.
*
Comment 13 Terrence Enger 2015-10-02 18:51:55 UTC
Created attachment 119212 [details]
backtraces compared, Win vs. Linux

I have tried to align the backtraces from Windows and Linux, looking
only at the function names.  Is this helpful?  Guidance welcome.
Comment 14 Yousuf Philips (jay) (retired) 2015-10-11 11:59:11 UTC
Would be great to get a dev to look into this crasher for Writer, as the crasher has become more easily triggerable in recent versions.
Comment 15 Buovjaga 2015-10-22 15:01:24 UTC
Cannot repro crash with steps from comment 3 or 11 anymore. I wonder, if something really changed? Plz retest, guys.

Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+
Build ID: fcc2415ade6ae93710bbbda9f7e163045e323105
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-10-21_16:55:13
Locale: fi-FI (fi_FI)
Comment 16 saurabhkukade 2016-01-21 17:09:46 UTC
I am unable to reproduce this bug. using debian and libreoffice Version: 4.3.3.2
Build ID: 430m0(Build:2)
Comment 17 Phil Krylov 2016-02-17 13:03:41 UTC
Version: 5.1.0.3
Build ID: 5e3e00a007d9b3b6efb6797a8b8e57b51ab1f737
CPU Threads: 2; OS Version: -; UI Render: default; 
Locale: en-US (en.UTF-8)
OS X 10.9

I can reproduce the crash with the steps from Comment 11 with N=18, backtrace:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000018
0x000000011c585094 in SwNoTextFrame::HasAnimation ()
(gdb) bt
#0  0x000000011c585094 in SwNoTextFrame::HasAnimation ()
#1  0x000000011c6773ea in SwFEShell::SelectObj ()
#2  0x000000011cd2fa68 in SwWrtShell::Do ()
#3  0x000000011cc05e39 in SwBaseShell::ExecUndo ()
#4  0x0000000100d12408 in SfxDispatcher::Call_Impl ()
#5  0x0000000100d0d39c in SfxBindings::Execute_Impl ()
#6  0x0000000100d457fc in SfxDispatchController_Impl::dispatch ()
#7  0x0000000100d43f27 in SfxOfficeDispatch::dispatch ()
#8  0x0000000111e88c34 in framework::MenuBarManager::Select ()
#9  0x0000000111e88569 in framework::MenuBarManager::LinkStubSelect ()
#10 0x0000000102a46c3d in Menu::Select ()
#11 0x0000000102ab48d3 in ImplWindowFrameProc ()
#12 0x0000000102d40f93 in AquaSalInstance::DoYield ()
#13 0x0000000102cce29e in Application::Yield ()
#14 0x0000000102cce238 in Application::Execute ()
#15 0x000000010007c7a2 in desktop::Desktop::Main ()
#16 0x0000000102cd2472 in ImplSVMain ()
#17 0x0000000102d40be4 in AquaSalInstance::handleAppDefinedEvent ()
#18 0x0000000102d758a4 in -[VCL_NSApplication sendEvent:] ()
#19 0x00007fff8d1839f9 in -[NSApplication run] ()
#20 0x00007fff8d16e783 in NSApplicationMain ()
#21 0x0000000102d3fef9 in ImplSVMainHook ()
#22 0x0000000102cd309a in SVMain ()
#23 0x00000001000a71b9 in soffice_main ()
#24 0x0000000100000f20 in main ()
Comment 18 Armin Le Grand (CIB) 2016-04-22 09:39:55 UTC
Could not reproduce using

Version: 5.2.0.0.alpha0+
Build ID: 29ad0f5d16c9f27fa3d12c3d1337a70cec976bbb
CPU Threads: 8; OS Version: Windows 6.1; UI Render: default; 
Locale: de-DE (de_DE)

Tried three times, with more or less graphics (different types). Got a crash after all undo after third try when starting to type, tried to reproduce, but seems not related (crash was in ImplBorderWindow::InitView() due to mpWindowImpl looking bad), could not recreate.
Comment 19 Julien Nabet 2016-05-27 13:35:57 UTC
Created attachment 125330 [details]
console bt logs

On pc Debian x86-64 with master sources updated today (+enable-dbgutil), I could reproduce the crash.

I attached console logs, bt + some gdb infos about the assert
Comment 20 Caolán McNamara 2016-06-07 20:43:13 UTC
When I select all, copy and paste I get internally a select area, a copy of that to a temp doc, delete of the selection and a paste from the temp doc to the document.

From the "delete" the graphic is not deleted, but it is pasted to the temp doc and pasted into the document. At this point there is two graphics. The undo seems to be "out" by the number of nodes involved in a graphic.

Seems to me that all would be a lot easier if anchored to paragraph acted like anchored to last character of the paragraph
Comment 21 Zenaan Harkness 2016-08-30 03:01:30 UTC
I confirm this still exists, by following the steps in comment #3, in LO5.3.0alpha.

I note the instructions had to be interpreted a bit - when "insert image", actually needed an extra paragraph (blank for me) at the end, before copying.

I inserted a GIF file.

I've seen this before and did not know why it happened, very good we have steps to reproduce.

Debian. Local build:
Build ID: 01cad4990d41ed06bb9c0504cef397121ee470f3
(2016-08-25)
Comment 22 Michael Meeks 2016-10-04 09:01:54 UTC
would be great to have a trace with debugging symbols on Linux or Windows - ultimately it looks like a NULL pointer de-reference =) could we bisect it ? =)
Comment 23 Terrence Enger 2016-10-07 15:44:13 UTC
@Michael

What kind of trace do you want?  We have backtraces on Linux and
Windows.  In a recent dbgutil build on Linux, I see the same function
names from the assertion down to about (IIRC) frame 48.

In comment 11, Matthew Francis reports reproducing the problem with
versions "back to the year dot".  I think this forecloses the
possibility of bisecting the bug, right?

I note that this bug covers at least an assertion (comments 12 and
19), an access violation (comments 4 and 7), and "Fatal Error"
(description and comment 3), as well as unspecific "crash".  Would it
be useful to split off the assertion, for example, into a separate bug
report?  My rationale for including the assertion, back at comment 12,
was merely that it happened with the same STR.
Comment 24 Michael Meeks 2016-10-07 16:31:24 UTC
Ah - yes, I see your nice trace now Terrence - thanks for that =) if it is an ancient bug, then yes no point in bisecting. The last thing that would be useful would be a valgrind trace - in case it is a memory corruption issue (it seems un-reliable - so quite possibly) rather than a simple logic bug.

Thanks !
Comment 25 Timur 2016-10-07 17:24:51 UTC
crashreport.libreoffice.org/stats/crash_details/beeff8a3-445c-4f90-8354-7929bd97ba46 for Comment 11
Comment 26 Timur 2016-10-07 17:35:48 UTC Comment hidden (no-value)
Comment 27 Michael Meeks 2016-10-07 17:58:04 UTC
Unfortunately the drmemory trace doesn't appear to show the crash itself, but has a lot of leak reports instead, many of which may be false positives. I'd really prefer a valgrind trace including the real crash, if we can get it; thanks !
Comment 28 Yousuf Philips (jay) (retired) 2016-10-07 18:11:13 UTC
For those wanting to do a valgrind, you can find instructions here.

https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_Valgrind_log
Comment 29 Julien Nabet 2016-10-07 21:21:52 UTC
Created attachment 127871 [details]
Valgrind trace

On pc Debian x86-64 with master sources updated today, I retrieved a Valgrind trace
Comment 30 Michael Meeks 2016-10-08 09:12:46 UTC
Thanks Julien - so not a memory corruption then ! just a logic error:

warn:svl:2367:1:svl/source/undo/undo.cxx:1171: SfxUndoManager::MarkTopUndoAction(): suspicious call!
warn:legacy.osl:2367:1:sw/source/core/attr/calbck.cxx:162: Client inserted while in Modify
warn:legacy.osl:2367:1:sw/source/core/access/acccontext.cxx:442: fire event for disposed frame?
warn:legacy.osl:2367:1:sw/source/core/access/acccontext.cxx:442: fire event for disposed frame?
warn:sw.core:2367:1:sw/source/core/attr/calbck.cxx:171: a 21SwAccessibleParagraph client added as listener to a 16SwTextFormatColl during client iteration.
warn:legacy.osl:2367:1:sw/source/core/access/accmap.cxx:1027: invalid event combination
warn:legacy.osl:2367:1:sw/source/core/doc/DocumentContentOperationsManager.cxx:2933: splitting non-text node?
warn:legacy.osl:2367:1:sw/source/core/undo/rolbck.cxx:517: SwHistoryChangeFormatColl: no ContentNode
soffice.bin: /home/julien/lo/libreoffice/sw/source/core/layout/atrfrm.cxx :1546 : void SwFormatAnchor::SetAnchor(const SwPosition*):  l'assertion « !pPos || ((FLY_AT_FLY == nAnchorId) && dynamic_cast<SwStartNode*>(&pPos->nNode.GetNode())) || (FLY_AT_PARA == nAnchorId && dynamic_cast<SwTableNode*>(&pPos->nNode.GetNode())) || dynamic_cast<SwTextNode*>(&pPos->nNode.GetNode()) » a échoué.
Comment 31 Xisco Faulí 2016-10-13 13:28:25 UTC Comment hidden (obsolete)
Comment 32 Telesto 2017-05-16 15:11:11 UTC
Still a repro with:
Version: 5.4.0.0.alpha1+
Build ID: 8c0be54a7da6262dffe04357121814dd22b5d7fe
CPU threads: 4; OS: Windows 6.2; UI render: default; 
TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2017-05-15_01:35:45
Locale: nl-NL (nl_NL); Calc: CL

crashreport.libreoffice.org/stats/crash_details/a7230ce5-f0f6-49d3-8335-f93c70c4d6b6
Comment 33 Telesto 2017-05-16 15:22:50 UTC Comment hidden (obsolete)
Comment 34 Julien Nabet 2017-05-20 06:01:21 UTC Comment hidden (obsolete)
Comment 35 Julien Nabet 2017-05-20 06:03:04 UTC Comment hidden (obsolete)
Comment 36 Julien Nabet 2017-05-20 06:43:04 UTC Comment hidden (obsolete)
Comment 37 Telesto 2017-05-20 17:54:03 UTC
Moving my 'shortcut' to bug 107973, because the crash signature differs and I can reproduce the SwNoTextFrame::HasAnimation() crash also.
Comment 38 Telesto 2017-05-20 18:48:39 UTC
Steps to reproduce this crash (HasAnimation()
1. Open attachment 119202 [details]
2. Press CTRL+A and CTRL+C
3. Position the cursor below the image
4. Press CTRL+V six times 
5. Press CTRL+Z seven times (after the fifth the image will disappear; crash follows on the seventh with SwNoTextFrame::HasAnimation()
Comment 39 Xisco Faulí 2017-05-21 13:22:18 UTC
Confirmed Telesto's steps from comment 38 in

Version: 5.5.0.0.alpha0+
Build ID: 7662b11cad6105d56fb9acc9c431c89d3b68dc89
CPU threads: 1; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2017-05-20_10:09:09
Locale: es-ES (es_ES); Calc: group
Comment 40 Timur 2017-05-30 08:33:14 UTC
(In reply to Xisco Faulí from comment #39)
> Confirmed Telesto's steps from comment 38
But why are there no bugs linked in http://crashreport.libreoffice.org/stats/signature/SwNoTextFrame::HasAnimation%28%29?
Like my http://crashreport.libreoffice.org/stats/crash_details/beeff8a3-445c-4f90-8354-7929bd97ba46.
Comment 41 Fyodor 2017-11-09 04:27:57 UTC
I can reliably reproduce this bug on Windows even with new document.
The Image should be anchored to last paragraph, and document should contain more than one paragraph.
If image anchored to some other paragraph, but not last, there is no crush.

During paste, image really isn't pasted, only paragraph's text. 
During undo not all steps undone, and crushes different every time.

I'm going to investigate this bug
Comment 42 Fyodor 2017-11-10 07:00:15 UTC
I did some code modifications and crush seems to gone for me, but I should check everything next week to make sure, that my assumptions are correct.

There is SwUndoInserts::m_FlyUndos array. It holds flys, which are previously been inserted and should be deleted during Undo (and deletion takes place on line 191 in core/undo/untblk.cxx), but...
This array holds ONLY flys, anchored to first* empty paragraph (if so). If fly is anchored to some other paragraph, or first paragraph is not empty, m_FlyUndos array left empty, and flys are deleted during text node deletion (I suspect, that they are deleted there :-)). If fly anchored to last empty paragraph, it also should be in m_FlyUndos, and be deleted by SwUndoInsLayFormat::UndoImpl (as for first node anchored fly). 

   *   By first and last paragraphs I mean first and last paragraphs in selection.

First and last paragraph handled separately (don't know why...)

m_FlyUndos populated in SwUndoInserts::SetInsertRange and only for first empty paragraph. 
I added condition to populate m_FlyUndos for last empty paragraph too, and bug is gone (seems that it gone...)

line 103 in core/undo/untblk.cxx should be
if( bScanFlys && (!nSttContent || !nEndContent))
line 115 should be
(nSttNode == pAPos->nNode.GetIndex() || nEndNode == pAPos->nNode.GetIndex()))
Comment 43 Michael Stahl 2017-11-10 11:58:44 UTC
i don't have time to look into this right now, but i remember that the question of which flys are deleted by undo is very tricky and several places in the code need to agree on it; see also https://bugs.documentfoundation.org/show_bug.cgi?id=107975#c9
Comment 44 Fyodor 2017-11-14 04:54:19 UTC
I further investigated this bug and tend to think that my ideas in comment 42 are correct.
What is happening with this document.
During paste, one paragraph with text and one empty paragraph with fly anchored to it are inserted. But due to bug in paste (I suspect that bug there), all pasted images anchored to last paragraph. So you see several identical text paragraph and one image. But there are several identical images lying one above another.

During Undo Flys are not deleted. This is due to strange behavior of DelContentIndex (https://opengrok.libreoffice.org/xref/core/sw/source/core/undo/untblk.cxx#177). It responsible for deleting flys during Undo, and it does so for any fly anchored to any paragraph but not first and last. First para excepted by  
bTmp = rMark.nNode < pAPos->nNode 
(https://opengrok.libreoffice.org/xref/core/sw/source/core/undo/undobj.cxx#975)
and last para excepted by
 rPoint.nNode.GetIndex() == pAPos->nNode.GetIndex() 
(https://opengrok.libreoffice.org/xref/core/sw/source/core/undo/undobj.cxx#989)

For last para, flys are just re-anchored to remaining para (Mark) and left in document. 
First para flys are cared in SwUndoInserts::UndoImpl, on line https://opengrok.libreoffice.org/xref/core/sw/source/core/undo/untblk.cxx#191. 

m_FlyUndos really used only for first para anchored flys. As of OpenGrok, it used only in three places in LO: in SwUndoInserts::UndoImpl and SwUndoInserts::RedoImpl for Undo/Redo and in SwUndoInserts::SetInsertRange where it is filled.
m_FlyUndos is surely duplicated code to DelContentIndex. And it is better to handle all flys in DelContentIndex, but as DelContentIndex  called from several places I don't want to modify it.

With flys left as is, on second Undo it going crazy. Undo store absolute start/end node indexes of part of the document, which should be deleted during undo. First Undo completed almost correctly as indexes are correct (almost, because FormatColl of last para doesn't restored). Second Undo tries to operate in the middle of the document, third undo may operate out of text nodes section (somewhere in flys section or between sections). At the end this leads to crush.

if correctly delete flys anchored to last para, indexes stored in Undo stayed correct, and no crush happens.

I see that modifying m_FlyUndos is less risky, as it used only in one class (SwUndoInsert). Modification of DelContentIndex can produce even more bugs, as it called from different places of LO.

Also I'm going to add comment for Undo/Redo to describe such complicated behavior.
Comment 45 Matthew Francis 2017-11-14 05:15:35 UTC
(In reply to Fyodor from comment #44)

Thanks for working on this. I still run into undo-related crashes regularly.

In addition to better comments, better unit tests to ensure the correct behaviour would I think be very useful here - especially given how easy it seems for regressions to be introduced when another person tackles a related bug
Comment 46 Buovjaga 2017-11-14 08:37:04 UTC
*** Bug 107973 has been marked as a duplicate of this bug. ***
Comment 47 Fyodor 2017-11-16 07:12:00 UTC
I've submitted a patch https://gerrit.libreoffice.org/#/c/44800/
Comment 48 Phil Krylov 2017-11-16 14:51:14 UTC
(In reply to Fyodor from comment #47)
> I've submitted a patch https://gerrit.libreoffice.org/#/c/44800/

Thanks! While your documentation effort sheds some light on undo internals for me, the indirect effects of your patch are still not clear enough. And the modification described in comment #42 differs from the one in the patch. Agreeing with comment #45, some tests seem to be really necessary for fixing this complex area.
Comment 49 Telesto 2017-11-16 15:15:58 UTC
A (silly?) non-developer question: does this fix have some 'entry point' to resolved the issue which commit 2903d85d6197829633d7f96c95cd55821c2c20ff attempt to fix, but partly failed because of bug 107975 (crash) (see also comment 43)
Comment 50 Fyodor 2017-11-17 00:31:18 UTC
(In reply to Telesto from comment #49)
> A (silly?) non-developer question: does this fix have some 'entry point' to
> resolved the issue which commit 2903d85d6197829633d7f96c95cd55821c2c20ff
> attempt to fix, but partly failed because of bug 107975 (crash) (see also
> comment 43)

All code I see make distinction between flys anchored to page, to paragraph and to char and process them differently.
Commit 2903d85d6197829633d7f96c95cd55821c2c20ff relates to flys anchored to char. It modified function IsDestroyFrameAnchoredAtChar, which used only twice and every time for char anchored flys (https://opengrok.libreoffice.org/search?project=core&project=cppunit&project=impress_remote&project=libabw&project=libcdr&project=libetonyek&project=libfreehand&project=libmspub&project=libpagemaker&project=libvisio&project=libzmf&project=online&project=sdk-examples&q=IsDestroyFrameAnchoredAtChar&defs=&refs=&path=&hist=&type=)

This bug and my modifications relates only to para anchored flys, so these bugs are unrelated.
Comment 51 Commit Notification 2018-01-26 13:56:49 UTC
Fyodor Yemelyanenko committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=70483089425d5bb22e036867290e06a6fc8d99fb

tdf#94225 - Writer crashes on Undo N times

It will be available in 6.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 52 Commit Notification 2018-01-26 16:12:29 UTC
Fyodor Yemelyanenko committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b9d14fbad622a05320eb90211ae2ba89edfb8148&h=libreoffice-6-0

tdf#94225 - Writer crashes on Undo N times

It will be available in 6.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 53 Timur 2018-01-29 07:57:26 UTC
I don't repro Comment 38 now.
Comment 54 Michael Stahl 2018-01-29 13:17:52 UTC
this should be fixed now, thanks Fyodor for the great work!