Bug 165156 - FILEOPEN: Hang on opening document with large keep-with-next table
Summary: FILEOPEN: Hang on opening document with large keep-with-next table
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
24.8.4.2 release
Hardware: All All
: medium normal
Assignee: Mike Kaganski
URL:
Whiteboard: target:26.2.0 target:25.2.6 target:25...
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Writer-Tables
  Show dependency treegraph
 
Reported: 2025-02-10 07:13 UTC by Phillip
Modified: 2025-07-14 12:48 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
sample document that hangs on load (17.35 KB, application/vnd.oasis.opendocument.text)
2025-02-10 07:13 UTC, Phillip
Details
sample document with a table removed, does not hang (17.26 KB, application/vnd.oasis.opendocument.text)
2025-02-10 07:13 UTC, Phillip
Details
sample document with a keep-with-next removed, does not hang (17.35 KB, application/vnd.oasis.opendocument.text)
2025-02-10 07:14 UTC, Phillip
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Phillip 2025-02-10 07:13:06 UTC
Created attachment 199094 [details]
sample document that hangs on load

I have a document that, when I try to open it in LO Writer, the process hangs forever.

The primary culprit *seems* to be a large table, where every row is marked as "keep-with-next", so it's trying to keep it all together on one page, but the table is too big to fit on a single page. But the hang is also very fragile, as I'd discovered while I was trying to find a minimal sample, if you at all change the size of the table (eg making one of the rows shorter by removing a linebreak) then the pagebreak hits a different part of the table, and it doesn't necessarily crash.

See attached sample_crashy.odt - the content here is a small table, then a paragraph with keep-with-next, and then the large table. This is trimmed down from an actual document that's many pages long, I've tried to trim it down as much as I can but there might still be some cruft in there, sorry.

I'm not sure what the first table has to do with it, but if I remove it, it no longer hangs, see attached sample_not_crashy_rm_table.odt

I'm suspecting the keep-with-next as being the issue, as if I remove keep-with-next from one of the cells in the table, it also no longer hangs, see attached sample_not_crashy_rm_keepwithnext.odt

Version: 24.8.4.2 (X86_64) / LibreOffice Community
Build ID: bb3cfa12c7b1bf994ecc5649a80400d06cd71002
CPU threads: 8; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win
Locale: en-AU (en_AU); UI: en-US
Calc: threaded
Comment 1 Phillip 2025-02-10 07:13:52 UTC
Created attachment 199095 [details]
sample document with a table removed, does not hang
Comment 2 Phillip 2025-02-10 07:14:15 UTC
Created attachment 199096 [details]
sample document with a keep-with-next removed, does not hang
Comment 3 m_a_riosv 2025-02-11 01:21:21 UTC
Reproducible
Version: 24.8.3.0.0+ (X86_64) / LibreOffice Community
Build ID: f7b102bc705d3bd98f7d2efa52c24eb6e2573642
CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded
and
Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 6042e60d69c40d1f307710e60a278cb286d68603
CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded

Latest version that works on the ones I have installed.
Version: 24.8.1.0.0+ (X86_64) / LibreOffice Community
Build ID: 2bf3cada925ca49e3ac6a249ec6c342954739986
CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded
Comment 4 Saburo 2025-02-11 07:55:06 UTC
bisected with linux-64-25.2
source f0baab027df46d4e74b7808ff5d976b8efb1ea33

tdf#152298: Handle "keep with next, allow split, span some rows" case

All the rows on the table in bugdoc require to be kept with next
(their first cells' first paragraphs have that flag). The layout
finds the table break position after row 39;  but then it checks
that that row should be kept with row 38,  that with row 37, and
so on.  The layout loop happens because the search for the break
position can't find a row.

But cell A38 spans over four rows;  in this case, Word checks if
this row can split, and splits the spanning cells, apparently as
keeping "part" of the row with next.

This change implements that algorithm.

Change-Id: I234694138ac6b660781ad773cef20151daf874eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173675
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Comment 5 Buovjaga 2025-07-13 09:10:07 UTC
(In reply to Saburo from comment #4)
> bisected with linux-64-25.2
> source f0baab027df46d4e74b7808ff5d976b8efb1ea33
> 
> tdf#152298: Handle "keep with next, allow split, span some rows" case

Saburo: please add the indicated developer to Cc when publishing bibisect results. Now it has been 5 months without Mike being aware of this.
Comment 6 Mike Kaganski 2025-07-13 09:19:19 UTC
Could someone please clarify how the stated version in the metadata aligns with this bug?
Comment 7 Saburo 2025-07-13 09:55:04 UTC
(In reply to Buovjaga from comment #5)

> Saburo: please add the indicated developer to Cc when publishing bibisect
> results. Now it has been 5 months without Mike being aware of this.

I'm sorry. I will be careful.
Comment 8 Saburo 2025-07-13 11:46:23 UTC
(In reply to Mike Kaganski from comment #6)
> Could someone please clarify how the stated version in the metadata aligns
> with this bug?

Since I was unable to reproduce the problem with Ver.7.4.7, I used Comment 3 written by m a riosv-san as a reference to bisect the problem.

Since there are no version information changes in the history, perhaps Phillip-san wrote the version that started using LibreOffice?
Comment 9 Buovjaga 2025-07-13 12:18:24 UTC
Assuming the version selection was a mis-click.
Comment 10 Mike Kaganski 2025-07-13 12:31:43 UTC
https://gerrit.libreoffice.org/c/core/+/187801
Comment 11 Commit Notification 2025-07-14 04:44:26 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/8946628f0ce28d111c9dfcfbd73e30afac32c157

tdf#165156: limit hack for tdf#161508 even more

It will be available in 26.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 12 Commit Notification 2025-07-14 11:12:20 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-25-2":

https://git.libreoffice.org/core/commit/29f44d08b17550a11bd68f6dcde0f7a1fb84641e

tdf#165156: limit hack for tdf#161508 even more

It will be available in 25.2.6.

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 Commit Notification 2025-07-14 12:48:36 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-25-8":

https://git.libreoffice.org/core/commit/a9bf303dfb348265edf7c2c61fc3b8a6511fd5df

tdf#165156: limit hack for tdf#161508 even more

It will be available in 25.8.0.2.

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.