Bug 138688 - Pasting Calc data into Writer table hangs Writer CRASH (steps in comment 4)
Summary: Pasting Calc data into Writer table hangs Writer CRASH (steps in comment 4)
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.3 all versions
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard: target:7.2.0 target:7.1.0.0.beta2 tar...
Keywords: bibisected, bisected, haveBacktrace, regression
Depends on:
Blocks:
 
Reported: 2020-12-06 01:34 UTC by Jim DeLaHunt
Modified: 2021-01-07 08:53 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Analysis of sampling soffice process during hang. (9.44 MB, text/plain)
2020-12-06 01:37 UTC, Jim DeLaHunt
Details
Test case LO Writer document demonstrating bug (11.73 KB, application/vnd.oasis.opendocument.text)
2020-12-06 03:16 UTC, Jim DeLaHunt
Details
Test case LO Writer document _not_ demonstrating bug (9.49 KB, application/vnd.oasis.opendocument.text)
2020-12-06 03:19 UTC, Jim DeLaHunt
Details
gdb bt (71.48 KB, text/plain)
2020-12-06 08:32 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jim DeLaHunt 2020-12-06 01:34:48 UTC
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.
Comment 1 Jim DeLaHunt 2020-12-06 01:37:07 UTC
Created attachment 167858 [details]
Analysis of sampling soffice process during hang.

Collected by macOS Activity Monitor, process info button, "Sample" button.
Comment 2 Jim DeLaHunt 2020-12-06 03:16:45 UTC
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.
Comment 3 Jim DeLaHunt 2020-12-06 03:19:35 UTC
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".
Comment 4 Jim DeLaHunt 2020-12-06 03:31:58 UTC
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.
Comment 5 Jim DeLaHunt 2020-12-06 03:32:51 UTC
(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.)
Comment 6 Jim DeLaHunt 2020-12-06 03:38:42 UTC
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.
Comment 7 Jim DeLaHunt 2020-12-06 03:41:12 UTC
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.
Comment 8 Julien Nabet 2020-12-06 08:32:05 UTC
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.
Comment 9 Julien Nabet 2020-12-06 08:33:49 UTC
Michael: thought you might be interested in this one since it concerns Writer.
Comment 10 Xisco Faulí 2020-12-07 09:50:32 UTC
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
Comment 11 Xisco Faulí 2020-12-07 10:03:47 UTC
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
Comment 12 Commit Notification 2020-12-10 09:17:28 UTC
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.
Comment 13 Jim DeLaHunt 2020-12-10 09:29:44 UTC
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!
Comment 14 Commit Notification 2020-12-10 13:10:13 UTC
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.
Comment 15 Commit Notification 2020-12-10 14:36:17 UTC
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.
Comment 16 László Németh 2020-12-10 17:10:45 UTC
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)
Comment 17 László Németh 2020-12-10 17:12:06 UTC
@Jim: many thanks for the bug report!
Comment 18 NISZ LibreOffice Team 2021-01-07 08:53:19 UTC
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