Bug 167295 - The program freezes when changing the table column size
Summary: The program freezes when changing the table column size
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
24.2.4.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: DOCX-Floatingtable
  Show dependency treegraph
 
Reported: 2025-06-30 11:42 UTC by Vladislav Tarakanov
Modified: 2025-07-07 07:47 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Document with bug (8.15 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2025-06-30 11:44 UTC, Vladislav Tarakanov
Details
Video of reproducing (1.04 MB, video/mp4)
2025-06-30 11:46 UTC, Vladislav Tarakanov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vladislav Tarakanov 2025-06-30 11:42:30 UTC
Description:
The program hangs when trying to change the column size or add some text to the cells of the attached document.

According to the debugger, the problem occurs in "sw/source/core/layout/flycnt.cxx", in the "while (true)" loop of the "GetNextFlyLeaf" method.

The problem is not reproduced in version 7.2, but has existed since at least version 24.2.4.

Version: 24.2.4.0.0+ (X86_64) / LibreOffice Community
Build ID: d1c31e3857b7f0c6b3fb72da0c967bfa2bdef015
CPU threads: 12; OS: Linux 6.6; UI render: default; VCL: kf5 (cairo+xcb)
Locale: ru-RU (ru_RU.UTF-8); UI: en-US
Calc: CL threaded

Steps to Reproduce:
1. Open the attached document
2. Reduce the size of the second column

Actual Results:
The program freezes

Expected Results:
The table size is changing


Reproducible: Always


User Profile Reset: No

Additional Info:
Steel repro on:
Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: ca48e42cc18b0988a02fc9ce594c3979601e7be0
CPU threads: 12; OS: Linux 6.6; UI render: default; VCL: kf5 (cairo+xcb)
Locale: ru-RU (ru_RU.UTF-8); UI: en-US
Calc: CL threaded
Comment 1 Vladislav Tarakanov 2025-06-30 11:44:21 UTC
Created attachment 201555 [details]
Document with bug
Comment 2 Vladislav Tarakanov 2025-06-30 11:46:04 UTC
Created attachment 201556 [details]
Video of reproducing
Comment 3 m_a_riosv 2025-06-30 12:13:58 UTC
Reproducible
Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: e7201fd7c51743cb103bae82263d98830f5174cf
CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win
Locale: en-US (es_ES); UI: en-US
Calc: CL threaded

Maybe it has some relation with the options:
- Add paragraph and table spacing at top of first page and page breaks
- Add paragraph and table spacing at bottom of table cells

Trying to modify this options and apply them, also hangs LO.
Comment 4 Saburo 2025-07-02 06:32:50 UTC
bibisected with linux-64-7.6
Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: ce3308a926f036b87515b8cd97d2b197063dc77a

author	Miklos Vajna
commit ce3308a926f036b87515b8cd97d2b197063dc77a

tdf#61594 sw floattable: import floating tables as split flys by default
To get wider testing.
Comment 5 Timur 2025-07-03 11:45:50 UTC
I checked this and got different bisect commit:
commit 262a1ae36eaf20e741759cd2c216456bbb472f7c	[log]
author	Miklos Vajna <vmiklos@collabora.com>	Wed Aug 02 09:56:49 2023 +0200
committer	Michael Stahl <michael.stahl@allotropia.de>	Thu Aug 03 11:55:19 2023 +0200
tdf#156260 sw floattable: avoid moving text from the last anchor to its precede
Comment 6 Vladislav Tarakanov 2025-07-04 20:25:24 UTC
As far as I can see, the cause of the current bug is the following:

The problem appears in the "while (true)" loop in "sw/source/core/layout/flycnt.cxx", method "GetNextFlyLeaf".

1 while iteration. In "if (bLeftBody || bLeftFly || bSameBody)"

1.1. pOldLayLeaf remembers the current value of pLayLeaf.
1.2. In the do...while loop below, pLayLeaf gets the value of pLayLeaf->GetNextLayoutLeaf(), which is nullptr.

2 while iteration. In the "else" branch of "if (pLayLeaf)" at the top level, in the case of "if (eMakePage == MAKEPAGE_INSERT)"

2.1 InsertPage is called
2.2 pLayLeaf gets the value of pOldLayLeaf

After 2.2 pLayLeaf gets the old value, for which "pLayLeaf->GetNextLayoutLeaf()" is still nullptr, which causes an infinite loop in the next while iterations.

Amin and I would like to try to fix this problem. Floating table issues affect many of our users who are trying to migrate from MS Office while keeping their existing docx files.

There may not be a specific commit that causes this regression, it looks more like a cumulative issue. Based on this, we have a question - is it expected that calling the "InsertPage" method will lead to changes in the pOldLayLeaf fields that will change the value of NextLayoutLeaf from nullprt to something else?
Comment 7 Miklos Vajna 2025-07-07 07:47:47 UTC
One way you can debug such a problem is to create a similar document with a multi-page section: i.e. a section that contains enough paragraphs that is spans over multiple pages. Then you can see how GetNextSctLeaf() works, the concept is really similar. If there is not enough space on the current page, optionally create a next page, find the potential anchor on that next page and create a follow fly frame there.

I intend to look at this myself, but I'm not yet sure where I'll have the time. When I do that, I'll comment here. Thanks.