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

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?

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

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.

(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 4.2.3.3
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 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

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

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)
https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Severity#Severity_Levels

Bug still in 5.1.0.3 win 8.1

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.

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

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?

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

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!

this is a 'Inherit from OOo' bug -> changing importance to High/major

Cannot reproduce with 6.3.0.0.alpha0+
What happened?

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.

Master build from today fails to open the original attachment:

Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 24d7431876e87eba700a9f141dc8e030143a92ad
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded