Description: I have a specific 23-page report in Writer, which includes a few tables and several headings. A few of the tables are populated by data from a Calc sheet. I update the table by deleting all but one row from the table in Writer, then copying replacement rows from the Calc sheet, and pasting into Writer. Writer hangs, I think in an infinite loop. The page content flickers as the table and following heading appear and disappear. LibreOffice runs at 100% of CPU, and doesn't stop even after several minutes. LibreOffice refuses all UI interaction. The only way out I have discovered is to force-quit LibreOffice. Steps to Reproduce: 1. Open a particular Writer test case document, which has multiple pages, headers, and a table near the end of a page, with a header after the table on the following page. (I will work on reducing my test case to a simpler test case which I can share.) 2. Scroll to the table near the end of a page, with a header after the table on the following page. This table has a header row and one content row. 3. Open a Calc spreadsheet with new content for the table. 4. Select a cell range 1 row high and the same number of columns wide as in the Writer table. 5. Edit… Copy 6. Switch to Writer window. 7. Click pointer before the first character of first cell of the content row of the table. 8. Edit… Paste. Actual Results: Writer hangs, in what appears to be an infinite loop. The pointer flickers back and forth between an arrow and an hourglass icon. The window contents flicker back and forth between two scroll positions, two page break positions, with the following header appearing to flicker into view then out. In macOS Activity Monitor, LibreOffice is running at approximately to 98.5-99.6% of one CPU. Sampling application process using macOS Activity Monitor shows a deep recursion through four execution locations. Process Sampling report attached. Expected Results: Data from clipboard replaces the existing content row of the table. LibreOffice UI becomes responsive within 1.0 seconds. Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.0.3.1 Build ID: d7547858d014d4cf69878db179d326fc3483e082 CPU threads: 8; OS: Mac OS X 10.13.6; UI render: default; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded First observed on LibreOffice 6.4.7. Reproduced with no visible differences after upgrading to LibreOffice 7.0.3. Table where I observe the bug is on page 20 of a 23-page report authored in Writer. I am not comfortable sharing this document as a test case, because I don't want to disclose the content and because it is likely more than we need to demonstrate the problem. I will attempt to reduce this document to a minimal test case. After the hang, and using Force Quit to stop LibreOffice, I run LibreOffice again. It offers to recover any documents which were open. This appears to succeed with no problem. Workaround: before the subject table, insert a paragraph "Safety page break", and format the paragraph to have a page break before or after. (Format… Paragaph… Text Flow… Breaks… check "Insert", accept Type: Page and Position: Before. The table is now at the top of a page. Then paste into the table. Then delete the "Safety page break" paragraph. This workaround has succeeded sometimes, and failed sometimes. The symbols which repeat from the Process Sample are: 1. SfxDispatcher::Execute(unsigned short, SfxCallMode, SfxPoolItem const**, unsigned short, SfxPoolItem const**) (in libsfxlo.dylib) + 640 [0x110579cb0] 2. SfxDispatcher::Call_Impl(SfxShell&, SfxSlot const&, SfxRequest&, bool) (in libsfxlo.dylib) + 607 [0x110577caf] 3. SwBaseShell::ExecClpbrd(SfxRequest&) (in libswlo.dylib) + 1615 [0x1c157af7f] 4. SwTransferable::Paste(SwWrtShell&, TransferableDataHelper&, RndStdIds, bool, PasteTableType) (in libswlo.dylib) + 3467 [0x1c14db03b] This sequence seems to repeat about 500 times in the sample report, then calls other functions.
Created attachment 167858 [details] Analysis of sampling soffice process during hang. Collected by macOS Activity Monitor, process info button, "Sample" button.
Created attachment 167861 [details] Test case LO Writer document demonstrating bug "Test case simplified from real life.odt" is a LibreOffice Writer document simplified from my original 23-page report which revealed the bug. The test case consists of: a paragraph styled "Text body", a table of 2 columns of table header and table contents, and finally a title styled "Heading 1". Following the simplified instructions to reproduce, this consistently demonstrates the bug.
Created attachment 167862 [details] Test case LO Writer document _not_ demonstrating bug "Test case simplified from real life.odt" is a LibreOffice Writer document created from a new, empty document to be identical to "Test case simplified from real life.odt". The test case consists of: a paragraph styled "Text body", a table of 2 columns of table header and table contents, and finally a title styled "Heading 1". But it obviously is not identical. Following the simplified instructions to reproduce, this consistently _fails_ to demonstrate the bug. Furthermore, after succeeded with this document, Writer no longer demonstrates the bug with "Test case simplified from real life.odt".
I now have a simplified test case document and Steps to Reproduce. Steps to Reproduce: 1. Open attached "Test case simplified from real life.odt" document in LO Writer. 2. Scroll to the table. This table has a header row and one content row. 3. Create a new empty Calc spreadsheet. 4. In any two side-by-side cells, type "new1" and "new2" (e.g. I use A1:B1) 5. Select these two cells. 6. Edit… Copy 7. Close the Calc spreadsheet. No need to save it. 8. Switch to Writer window. 9. Click pointer before the first character of first cell of the content row of the table. 10. Edit… Paste. Actual Results: Writer hangs, in what appears to be an infinite loop. The pointer flickers back and forth between an arrow and an hourglass icon. The window contents flicker back and forth between the pasted new cells embedded within the first cell of the existing table, and the new calls replacing the entire existing row of the table. In macOS Activity Monitor, LibreOffice is running at approximately to 98.5-99.6% of one CPU. (Did not sampling application process using macOS Activity Monitor.) Expected Results: Data from clipboard replaces the existing content row of the table. LibreOffice UI becomes responsive within 1.0 seconds. Negative test case: perform the same Steps to Reproduce, but use the attached "Test case made new.odt" document instead "Test case simplified from real life.odt". In this case the bug does not appear. The Actual Results match the Expected Results.
(In reply to Jim DeLaHunt from comment #3) > Created attachment 167862 [details] > Test case LO Writer document _not_ demonstrating bug > > "Test case simplified from real life.odt" is a LibreOffice Writer document > created from a new, empty document… Sorry, the attachment is actually named "Test case made new.odt". (Copy/paste error, sorry.)
Some other discoveries about this bug. 1. If I try and fail to reproduce the bug using "Test case made new.odt", then I open "Test case simplified from real life.odt" (re-using the two-cell table in the clipboard), then the bug does not occur. Could it be that the procedure succeeding changes either the clipboard contents or the state of the running LibreOffice to avoid the bug. 2. If, having performed #1 and discovered that the bug does not occur with "Test case simplified from real life.odt", I then quit LibreOffice, reopen "Test case simplified from real life.odt", and redo the Steps to Reproduce copying the table again from Calc, then the bug does occur. 3. If modify "Test case simplified from real life.odt" to remove the paragraph styled "Heading 1" after the table, then the bug does not occur. 4. If I modify the Steps to Reproduce by pasting the table data (from Calc) into a new, empty Writer document first, then copy that table and paste into the "Test case simplified from real life.odt", the bug does not appear.
Changing title to better reflect that I know from the two simplified test cases. I don't see a way to update the description, but it clearly is not completely accurate based on what I know now.
Created attachment 167863 [details] gdb bt On pc Debian x86-64 with master sources updated today, I could reproduce this. I attached console logs + bt. Both show a kind of infinite loop or recursion.
Michael: thought you might be interested in this one since it concerns Writer.
Not reproducible in Version: 5.4.0.0.alpha1+ Build ID: 9feb7f7039a3b59974cbf266922177e961a52dd1 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); Calc: group
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=0c3ac02d8a3c7ea50ae262daf134c28df5c8b343 author László Németh <nemeth@numbertext.org> 2019-04-06 09:27:35 +0200 committer László Németh <nemeth@numbertext.org> 2019-04-10 17:14:45 +0200 commit 0c3ac02d8a3c7ea50ae262daf134c28df5c8b343 (patch) tree 9ad0b84e6c06f30a190d62078daaf0f0a82465b4 parent 9d63c7035a86bb3a355433b567d2d8cd53d582fa (diff) tdf#124646 Don't paste hidden rows of Calc sheets into Writer tables Bisected with: bibisect-linux64-6.3 Adding Cc: to László Németh
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7720f8cf22718415adb3db2304916581f864f884 tdf#138688 tdf#124646 sw: fix crash at pasting Calc data It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thank you for the fix! I'm just an ordinary LibreOffice user, but it feels great to have been able to contribute, even if all I did was to file a helpful bug report. Thank you for making my contribution matter!
László Németh committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/e7065337630d414bd17e626155fa4e9fc5a2e29d tdf#138688 tdf#124646 sw: fix crash at pasting Calc data It will be available in 7.1.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
László Németh committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/c8d335f9bfa6a6fd0887171e2b51035dcbb42078 tdf#138688 tdf#124646 sw: fix crash at pasting Calc data It will be available in 7.0.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Full description of the fix: tdf#138688 tdf#124646 sw: fix crash at pasting Calc data .. in a table before a numbered paragraph. Dispatcher calls of the workaround for tdf#124646 missed the temporary table in this case, selecting + copying nothing and after that trying to paste the same non-native Calc data again, resulting infinite recursion. Replacing FN_CHAR_LEFT with FN_LINE_UP solved the problem (FN_CHAR_LEFT selected the numbers of the numbered list instead of the temporary table). Fixing the fragile dispatcher calls, now we check the selection of the temporary table to avoid similar crashes. Unit tests are added for the fix, also for the original problem of tdf#124646 (avoid copying hidden rows from Calc, e.g. copying only visible result of a filtering). Regression from commit 0c3ac02d8a3c7ea50ae262daf134c28df5c8b343 (tdf#124646 Don't paste hidden rows of Calc sheets into Writer tables). (Note: to check/show the fix of the crash manually, run the test with $ (cd sw && make -srj8 UITest_sw_table UITEST_TEST_NAME="sheetToTable.sheetToTable.test_tdf138688" SAL_USE_VCLPLUGIN=gen) adding import time time.sleep(5) to the called function of sheetToTable.py)
@Jim: many thanks for the bug report!
Verified in: Version: 7.2.0.0.alpha0+ (x64) Build ID: 96bafa464ebdbce3ef04bec9beae5e745bb37794 CPU threads: 4; OS: Windows 10.0 Build 17134; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: hu-HU Calc: threaded