Bug Hunting Session
Bug 73805 - EDITING: Layout Loop when writing into a section with 3 columns
Summary: EDITING: Layout Loop when writing into a section with 3 columns
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: high major
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
: 79636 (view as bug list)
Depends on:
Blocks: Layout-Loops, Writer-Loops
  Show dependency treegraph
 
Reported: 2014-01-19 18:12 UTC by Reversed suomynonA
Modified: 2019-10-20 16:37 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
The test document (appending further text causes error) (10.00 KB, application/vnd.oasis.opendocument.text)
2014-01-19 18:12 UTC, Reversed suomynonA
Details
Similar (same?) problem with frame and section (8.47 KB, application/vnd.oasis.opendocument.text)
2018-10-09 10:23 UTC, Simon
Details
test file repaired at the cost of the loss of styles. (8.83 KB, application/vnd.oasis.opendocument.text)
2019-10-20 16:37 UTC, Jean-Baptiste Faure
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Reversed suomynonA 2014-01-19 18:12:24 UTC
Created attachment 92410 [details]
The test document (appending further text causes error)

Problem description: When I write more than two lines in a section consisting of three columns, LO-Writer crashes.

Steps to reproduce:
1. Open attached document
2. Append any text to the first column.

Current behavior: The application stops working.

Expected behavior: The application should continue working and the entered text should be wrapped to the second column.

              
Operating System: Windows (other)
Version: 4.1.4.2 release
Comment 1 Ken Biondi 2014-01-19 19:43:20 UTC
I confirm this bug on the two versions below.  I'm changing the priority to highest blocker since this bug causes frequent freezes.

I tested using:
WIN 8
x86-64
Version: 4.2.0.2
Build ID: cd65d6220c5694ee7012d7863bcde3455c9e3c30
and
Version: 4.1.4.2
Build ID: 0a0440ccc0227ad9829de5f46be37cfb6edcf72
Comment 2 Julien Nabet 2014-01-20 21:25:33 UTC
On pc Debian x86-64 with master sources updated today, I can reproduce this.

I tried some gdb and noticed this:
3       breakpoint     keep y   0x00002aaac8e98b66 in SwLayoutFrm::ContainsCntnt() const 
                                                   at /home/julien/compile-libreoffice/libo/sw/source/core/layout/findfrm.cxx:105
	breakpoint already hit 691 times
See http://opengrok.libreoffice.org/xref/core/sw/source/core/layout/findfrm.cxx#80

Michael: one for you?
Comment 3 Jean-Baptiste Faure 2014-01-22 11:23:07 UTC
Tested with versions master, 4.2.1.0.0+ and 4.2.0.2 on Ubuntu 13.10 x86-64. No crash for me but LO freezes with what seems an infinite loop.
 
There is something strange in the test file: 
1/ it has 2 lines in the first column and nothing in column 2 and 3
2/ the section is formatted with the option "Evenly distribute contents to all columns"
These 2 facts are incompatible: with 2/ we should have one line in column 1 and one line in column 2.

If I go to Format > Section > Options > Tab Column and uncheck the option, then I do not reproduce the freeze anymore. If I insert some text, go back to the column tab and recheck this option, it still works as expected.

Last thing, I can't reproduce the problem from an empty file:
a/ insert a section with 3 columns
b/ type some text in column 1
whatever is the option chosen for the text distribution in the columns.

Hope this helps. Best regards. JBF
Comment 4 Michael Stahl (CIB) 2014-01-22 12:55:43 UTC
that's amazing - this loops (on Linux) in every version of LO and OOo i tried,
back to OOo 3.0.1.  so no regression.  but very good reproducer document :)

lots of assertions like this:
warn:legacy.osl:6156:1:sw/source/core/layout/flowfrm.cxx:2532: <SwFlowFrm::MoveBwd(..)> - layout loop control for layout action <Move Backward> applied!
warn:legacy.osl:6156:1:sw/source/core/layout/layact.cxx:851: LoopControl_2 in Interrupt formatting in SwLayAction::InternalAction


with 2 or 4 or 5 columns it doesn't loop.

un-checking "Evenly distribute contents to all columns" makes it not loop.

if the first-line indent of the paragraph in the section is set to 0
then it loops just for a couple of seconds and the document is then
editable again.
Comment 5 Michael Stahl (CIB) 2014-01-22 12:58:09 UTC
(In reply to comment #3)
> There is something strange in the test file: 
> 1/ it has 2 lines in the first column and nothing in column 2 and 3
> 2/ the section is formatted with the option "Evenly distribute contents to
> all columns"
> These 2 facts are incompatible: with 2/ we should have one line in column 1
> and one line in column 2.

i guess Widow / Orphan settings have something to do with this.
Comment 6 tommy27 2014-05-02 13:53:19 UTC
freeze still reproducible under Win7x64 using 4.2.3.3
moving it to mab4.2 list since 4.1.x is END OF LIFE
Comment 7 Julien Nabet 2014-05-28 17:39:52 UTC
Just for information, I can reproduce this on pc Debian x86-64 with master sources updated yesterday.
Comment 8 Michael Stahl (CIB) 2014-06-05 11:34:08 UTC
*** Bug 79636 has been marked as a duplicate of this bug. ***
Comment 9 tommy27 2014-12-08 10:43:08 UTC
retested under Win8.1 x64
both LibO 4.3.4.1 and 4.5.0.0alpha freeze after adding text to 1st column

moving bug to mab4.3 list since 4.2.x is EOL
Comment 10 Gordo 2015-06-30 13:53:59 UTC
I can reproduce this from scratch.

1. New Text Document.
2. Press Enter (if no empty paragraph then red arrow syndrome).
3. Insert → Section → Columns → 3 and Insert.
4. Place cursor in section and right click → Paragraph → Text Flow → check both Orphan and Widow control and OK.
5. Save and reload document.
6. Type enough text for two lines in the first column.
7. Save and reload document.
8. Place cursor at the end of the text in the first column of the section and type some more text.
Result:
Hang.

If step 2 is left out then the cursor disappears to the right while typing.  After saving, additional text causes a red arrow to pop up in the first column.

Windows Vista 64
Version: 4.4.4.3
Build ID: 2c39ebcf046445232b798108aa8a7e7d89552ea8
Comment 11 Julien Nabet 2015-09-12 13:45:52 UTC
On pc Debian x86-64 with master sources updated today, I could reproduce the loop with Gordo's example.
I noticed these logs on console:
warn:legacy.osl:24138:1:sw/source/core/layout/flowfrm.cxx:2395: <SwFlowFrm::MoveBwd(..)> - layout loop control for layout action <Move Backward> applied!
Comment 12 Robinson Tryon (qubit) 2015-10-07 21:58:18 UTC
Dropping Severity -> critical (we've deprecated the 'blocker' value)
https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Severity#Severity_Levels
Comment 13 Andrew 2016-02-16 05:50:08 UTC
Bug still in 5.1.0.3 win 8.1
Comment 14 Jens Harms 2017-03-22 08:52:25 UTC
If i open the attached document in libreoffice-writer the program immediatly crashes.

Version: 5.2.2.2
Build-ID: 1:5.2.2-0ubuntu2
CPU-Threads: 8; BS-Version: Linux 4.8; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group
Arch: AMD64


This bug is most probably related to this bug:

[Bug 79253] While editing text in table, writer application freezes. Work since last save could not be recovered.
Comment 15 QA Administrators 2018-03-23 03:35:07 UTC Comment hidden (obsolete)
Comment 16 globefish 2018-03-23 18:25:48 UTC
I can reproduce the bug according to Gordo's example running...

Version: 6.0.2.1
Build-ID: f7f06a8f319e4b62f9bc5095aa112a65d2f3ac89
CPU-Threads: 12; BS: Linux 4.4; UI-Render: Standard; VCL: kde4; 
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group

Linux ara 4.4.114-42-default #1 SMP Tue Feb 6 10:58:10 UTC 2018 (b6ee9ae) x86_64 x86_64 x86_64 GNU/Linux

libreoffice still freezes
Comment 17 Simon Wilper 2018-04-23 19:55:12 UTC
Can reproduce with latest git checkout 6.1.0.0.alpha0+.

I also cannot even get the bugdoc open and the office gets stuck in an endless loop of calls to SwLayoutFrame::MakeAll(vcl::RenderContext*) what gets called from SwSectionFrame::MakeAll(vcl::RenderContext*).

There at the top a so-called StackHack is queried and the function is left when the count is greater that a hardcoded 50. When I examined the stack size when opening the document it never grows > 1.

So when I change the 50 to 0 I can get the document open but as it seems the multicolumn section does not appear. Obviously this is the wrong way to do it but where do you intervene? Before or after MakeAll() or not even remotely there?
Comment 18 Simon 2018-10-09 10:23:14 UTC
Created attachment 145514 [details]
Similar (same?) problem with frame and section

The document shows what I suspect to be the same bug. It has a frame with fixed width and height. In that frame is a single-column section with some text.

As is, the document opens fine. Adding a new line at the top of the section in the frame, will cause writer to freeze (100% CPU usage).

This is on ArchLinux x86_64, 4.18.12. 
LO version 6.0.6.2
Comment 19 Tyco72 2019-02-21 08:47:07 UTC
With LO 6.1.5.2 (x64) on Win7 it is even worst. The attached odt file can't be opened at all. LO freezes directly!
Comment 20 Xisco Faulí 2019-05-15 15:44:23 UTC
this is a 'Inherit from OOo' bug -> changing importance to High/major
Comment 21 Simon Wilper 2019-10-13 16:12:06 UTC
Cannot reproduce with 6.3.0.0.alpha0+
What happened?
Comment 22 Jean-Baptiste Faure 2019-10-20 16:34:15 UTC
I still have problem to open the test file with LO 6.3.x et current master under Ubuntu.
Removing styles.xml from the archive, fixes the problem for me, both to open the file and write in it.

How I proceeded:
1/ rename error.odt in error.zip
2/ uncompress error.zip ; I got a directory named error
3/ opened this directory with my file explorer (here nautilus)
4/ deleted styles.xml file
5/ ctrl+A to select all in the directory
6/ right click et choose compress entry
7/ choose zip format for the archive and give it a name
8/ rename the archive with odt extension instead of zip
9/ open the new odt file 

That does not explain why there is a problem in the original file, but that gives you a workaround to retrieve the content of the document.

Hope that helps.
Best regards. JBF
Comment 23 Jean-Baptiste Faure 2019-10-20 16:37:50 UTC
Created attachment 155165 [details]
test file repaired at the cost of the loss of styles.