https://bugs.documentfoundation.org/show_bug.cgi?id=174066
Bug ID: 174066
Summary: Writer hangs when refreshing a DOCX containing nested
floating tables
Product: LibreOffice
Version: 26.8.0.3 release
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Writer
Assignee: [email protected]
Reporter: [email protected]
Created attachment 209216
--> https://bugs.documentfoundation.org/attachment.cgi?id=209216&action=edit
example docx file for reproducind the bug
Imported docx file hangs during repeated refresh in a docx-to-pdf converter.
Also reproduces in focused Writer test.
Attached docx file imports but calling
com.sun.star.util.XRefreshable::refresh() twice hangs Writer on table layout
step until killed by test timeout. Layout code repeatedly retries failed table
split without moving the table.
Patch was developed, tested and runs in prod.
Steps to reproduce:
1. Import attached docx file into Writer.
2. Obtain com.sun.star.util.XRefreshable from the document.
3. Call refresh() twice on the document.
4. Observe that refresh sequence spins CPU until timeout.
Actual result:
Focused test times out in 30 seconds on both unpatched versions named below.
Import alone completes fine.
Expected result:
Both refresh calls return. Document keeps its tables, has 0 repeated header
rows in each table, and layout is single page.
Test environments:
Fedora 44 x86-64
Ubuntu 24.04 x86-64 in WSL2
Versions tested:
- master, 27.2.0.0.alpha0+:022c34f162f94d59499ec48e48edbfd075f583b0
- libreoffice-26-8, 26.8.3.0.0+:5d804a6c79d59dc946d12d5018d48d30460fdc32
- Release 26.8.1.1, source tag
libreoffice-26.8.1.1:bf6ef2662401c7d6dce671ab4deb26ee0af3a7c1
- Release 26.8.0.3, source tag
libreoffice-26.8.0.3:bce0998afefdbc355585ca324285661a2170ba77
Related reports:
Checked 163367, 170477, 171387 - no duplicate confirmed.
174012 - possible relation, have not checked yet.
Reproducing test:
1. Save attached file as:
sw/qa/core/layout/data/nested-floating-tables-refresh.docx
2. Add includes to sw/qa/core/layout/tabfrm.cxx :
#include "com/sun/star/text/XTextTablesSupplier.hpp"
#include "com/sun/star/util/XRefreshable.hpp"
3. Add test inside existing anonymous namespace, near the other
CPPUNIT_TEST_FIXTURE tests:
CPPUNIT_TEST_FIXTURE(Test, testNestedFloatingTablesRefresh)
{
createSwDoc("nested-floating-tables-refresh.docx");
uno::Reference<util::XRefreshable> xRefreshable(mxComponent,
uno::UNO_QUERY_THROW);
xRefreshable->refresh();
xRefreshable->refresh();
CPPUNIT_ASSERT_EQUAL(1, getPages());
uno::Reference<text::XTextTablesSupplier> xTables(mxComponent,
uno::UNO_QUERY_THROW);
auto xTableNames = xTables->getTextTables();
CPPUNIT_ASSERT_EQUAL(sal_Int32(4),
xTableNames->getElementNames().getLength());
for (const OUString& rName : xTableNames->getElementNames())
{
CPPUNIT_ASSERT_EQUAL(
sal_Int32(0),
getProperty<sal_Int32>(xTableNames->getByName(rName),
u"HeaderRowCount"_ustr));
}
}
Investigation:
Documents, both original and sanitized (attachment here) were tested directly
in Writer. Import completed fine; repeated refresh reproduced hanging.
Hanging was traced to SwTabFrame::MakeAll. Anchor-follow condition keeps
setting bTryToSplit back to true after failed split, but the table did not move
or gain space. During investigation, was found that same path also changes
repeated-header count from 0 to 1 via SetRowsToRepeat(1).
Two changes were tested alone and together:
- Guard header fallback: still hangs.
- Remove anchor-follow retry: refresh completes, but the table gains repeating
header.
- Both changes: refresh completes and no repeating headers appear.
Attached docx was tested in unpatched and patched builds of master
(022c34f162f94) and libreoffice-26-8 (5d804a6c79d5). Both unpatched tests hang
until timeout kill. Patched tests run correctly.
Patch was backported to 26.8.0.3 and later 26.8.1.1 for use in gotenberg
service as docx-to-pdf converter. Both versions were/are running in our prod.
AI assistance:
OpenAI Astra 6 (Codex) was used for debugging and executing builds and tests.
Code for test and proposed patch is trivial and was done by hand.
--
You are receiving this mail because:
You are the assignee for the bug.
