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
Could not reproduce. Win 7 Pro 64-bit, Version: 5.0.1.2 (32-bit) Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261 Locale: fi-FI (fi_FI)
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)
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.
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)
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
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/
(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
Reproduced on Linux (Ubuntu 14.04) Bibisect daily dbgutil repo, 2015-09-18: source-hash-9ce08dcc2e32c5554ddf71b79173f8854e0568ad Setting OS back to All
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.
(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?
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
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. *
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.
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.
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)
I am unable to reproduce this bug. using debian and libreoffice Version: 4.3.3.2 Build ID: 430m0(Build:2)
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 ()
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.
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
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
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)
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 ? =)
@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.
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 !
crashreport.libreoffice.org/stats/crash_details/beeff8a3-445c-4f90-8354-7929bd97ba46 for Comment 11
Created attachment 127864 [details] DrMemory logs.zip Are those of help instead of valgrind? It's Windows access violation.
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 !
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
Created attachment 127871 [details] Valgrind trace On pc Debian x86-64 with master sources updated today, I retrieved a Valgrind trace
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é.
@Raal, would you mind
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
Steps to reproduce (shortcut) 1. Open attachment 119202 [details] 2. Type below the image 'AAA' 3. Press CTRL+A and CTRL+C 4. Deselect AAA 4. Press enter to add a new line below AAA 5. CTRL+V 6. Three times CTRL+Z -> Crash
Created attachment 133411 [details] bt with debug symbols On pc Debian x86-64 with master sources updated yesterday, I still reproduce this but with a different bt. I used Telesto's reproduce case.
Here is the state of nodes: (gdb) p aNd $5 = SwNodeIndex (node 13) (gdb) p aNd.GetNode() $6 = (SwNode &) @0x5555578be330: {<BigPtrEntry> = {_vptr.BigPtrEntry = 0x7fffca6162f0 <vtable for SwEndNode+16>, m_pBlock = 0x5555578be240, m_nOffset = 13}, m_nNodeType = SwNodeType::End, m_nAFormatNumLvl = 0 '\000', m_bSetNumLSpace = false, m_bIgnoreDontExpand = false, static s_nSerial = 82, m_nSerial = 7, m_pAnchoredFlys = std::unique_ptr<std::__debug::vector<SwFrameFormat*, std::allocator<SwFrameFormat*> >> containing 0x0, m_pStartOfSection = 0x5555578be490} (gdb) p nNode $7 = 13 (gdb) p pTmpDoc->GetNodes() $8 = (SwNodes &) @0x5555578add80: {<BigPtrArray> = BigPtrArray of length 19 = { [ 0] 0x5555578a79c0 StartNode , [ 1] 0x5555578a6cb0 EndNode , [ 2] 0x5555578a8ab0 StartNode , [ 3] 0x555557898320 EndNode , [ 4] 0x555557898f00 StartNode , [ 5] 0x555557aeb780 StartNode , [ 6] 0x555557aeb230 GrfNode , [ 7] 0x555557ae9670 EndNode , [ 8] 0x55555c328620 StartNode , [ 9] 0x55555c90cc30 GrfNode , [ 10] 0x555557829080 EndNode , [ 11] 0x5555578be1b0 EndNode , [ 12] 0x5555578be490 StartNode , [ 13] 0x5555578be330 EndNode , [ 14] 0x5555578be3c0 StartNode , [ 15] 0x5555578d7ba0 TextNode "Qwe qwe qwe qwe", [ 16] 0x555557990b10 TextNode "AAA", [ 17] 0x55555ca16960 TextNode "", [ 18] 0x5555578be2a0 EndNode }, m_vIndices = 0x5555578d71f8, m_pMyDoc = 0x5555578be590, m_pEndOfPostIts = 0x5555578a6cb0, m_pEndOfInserts = 0x555557898320, m_pEndOfAutotext = 0x5555578be1b0, m_pEndOfRedlines = 0x5555578be330, m_pEndOfContent = 0x5555578be2a0, m_pOutlineNodes = 0x555557898430, m_bInNodesDel = false, m_bInDelUpdOutline = false}
It seems nNode = 13 is wrong since it's obviously not a content but don't know how to track down the evolution of list of nodes. Indeed, I'd like to dump the list before starting to undo and after each undo. Also nNode (which isn't a local var here) should be renamed so it would avoid to retrieve lots of results in Opengrok.
Moving my 'shortcut' to bug 107973, because the crash signature differs and I can reproduce the SwNoTextFrame::HasAnimation() crash also.
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()
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
(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.
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
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()))
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
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.
(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
*** Bug 107973 has been marked as a duplicate of this bug. ***
I've submitted a patch https://gerrit.libreoffice.org/#/c/44800/
(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.
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)
(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.
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.
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.
I don't repro Comment 38 now.
this should be fixed now, thanks Fyodor for the great work!