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: 184.108.40.206 release
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:
Build ID: cd65d6220c5694ee7012d7863bcde3455c9e3c30
Build ID: 0a0440ccc0227ad9829de5f46be37cfb6edcf72
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
breakpoint already hit 691 times
Michael: one for you?
Tested with versions master, 220.127.116.11.0+ and 18.104.22.168 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
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
(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.
freeze still reproducible under Win7x64 using 22.214.171.124
moving it to mab4.2 list since 4.1.x is END OF LIFE
Just for information, I can reproduce this on pc Debian x86-64 with master sources updated yesterday.
*** Bug 79636 has been marked as a duplicate of this bug. ***
retested under Win8.1 x64
both LibO 126.96.36.199 and 188.8.131.52alpha freeze after adding text to 1st column
moving bug to mab4.3 list since 4.2.x is EOL
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.
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
Build ID: 2c39ebcf046445232b798108aa8a7e7d89552ea8
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!
Dropping Severity -> critical (we've deprecated the 'blocker' value)
Bug still in 184.108.40.206 win 8.1
If i open the attached document in libreoffice-writer the program immediatly crashes.
CPU-Threads: 8; BS-Version: Linux 4.8; UI-Render: Standard;
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group
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.
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
I can reproduce the bug according to Gordo's example running...
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
Can reproduce with latest git checkout 220.127.116.11.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?
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 18.104.22.168
With LO 22.214.171.124 (x64) on Win7 it is even worst. The attached odt file can't be opened at all. LO freezes directly!
this is a 'Inherit from OOo' bug -> changing importance to High/major
Cannot reproduce with 126.96.36.199.alpha0+
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
Created attachment 155165 [details]
test file repaired at the cost of the loss of styles.