Bug 148365 - CRASH: Writer 7.4 enters infinite loop while opening DOCX file (high CPU, previously hangup)
Summary: CRASH: Writer 7.4 enters infinite loop while opening DOCX file (high CPU, pre...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.4.0.0 alpha0+
Hardware: All All
: medium normal
Assignee: Attila Bakos (NISZ)
URL:
Whiteboard: target:7.4.0 target:7.3.5
Keywords:
Depends on:
Blocks:
 
Reported: 2022-04-04 12:10 UTC by Rafael Lima
Modified: 2022-06-09 17:08 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
DOCX file where the problem occurs (842.77 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2022-04-04 12:10 UTC, Rafael Lima
Details
Bibisect log (2.74 KB, text/plain)
2022-04-08 08:44 UTC, Telesto
Details
Bibisect log (4.20 KB, text/plain)
2022-04-08 10:19 UTC, Telesto
Details
Works fine at me (259.34 KB, image/jpeg)
2022-04-08 10:53 UTC, Attila Bakos (NISZ)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rafael Lima 2022-04-04 12:10:56 UTC
Created attachment 179304 [details]
DOCX file where the problem occurs

The attached file opens fine in 7.2 and 7.3. However, in LO 7.4 it enters some sort of infinite loop and LO stops responds

In the terminal I keep getting an infinite stream of the following warning message.

warn:legacy.osl:201586:201586:sw/source/core/layout/objectformatter.cxx:326: LoopControl in SwObjectFormatter::FormatObj_: Stage 3!!!

To reproduce the bug, run the current master build of LO 7.4 alpha from the terminal and open the attached file. The  notice that the message above will keep coming infinitely and LO will become unusable.

System info:
Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: c2e8a96a8107a37901e475c65a8e61211fc3b132
CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb)
Locale: pt-BR (pt_BR.UTF-8); UI: en-US
Calc: CL
Comment 1 Xisco Faulí 2022-04-04 14:13:35 UTC
I can't reproduce it in

Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 9f0e19721bb598c75835cfa94f4158085f81288e
CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3
Locale: es-ES (es_ES.UTF-8); UI: en-US
Calc: threaded
Comment 2 Xisco Faulí 2022-04-04 14:14:39 UTC
Not with

Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 9f0e19721bb598c75835cfa94f4158085f81288e
CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: x11
Locale: es-ES (es_ES.UTF-8); UI: en-US
Calc: threaded
Comment 3 Telesto 2022-04-04 14:15:59 UTC
Repro
Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 52ef78f4923283e6e52d575bec81985b031cb30b
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL Jumbo
Comment 4 Xisco Faulí 2022-04-04 14:18:10 UTC Comment hidden (obsolete)
Comment 5 Roman Kuznetsov 2022-04-04 17:14:28 UTC Comment hidden (obsolete)
Comment 6 Rafael Lima 2022-04-04 17:33:20 UTC
> I see 100% CPU loading (in oldest and in master builds in 7-4 bisect repo)
> but I couldn't get the LO's hanging/crash
> 
> I need some clear steps...

Hi Roman! I ran it by building the master branch on my PC today.

After building it, I launched Writer from the terminal:
./instdir/program/soffice --writer

And then from within Writer, I open the sample DOCX file (Attachment 179304 [details]).

After that, from the terminal I keep getting an infinite loop of the following message:

warn:legacy.osl:201586:201586:sw/source/core/layout/objectformatter.cxx:326: LoopControl in SwObjectFormatter::FormatObj_: Stage 3!!!

On my PC, Writer becomes unusable after that and the only way to get around it is by pressing Ctrl + C in the terminal.
Comment 7 Rainer Bielefeld Retired 2022-04-05 04:29:40 UTC
REPRODUCIBLE with Server Installation of Version: 7.4.0.0.alpha0+ (x64)  Build ID c856f9bec12d98ed49f01578ded79f16ae7be051
CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-US  |  Calc: CL  |  Auto Colibre Theme  |  Special devUserProfile
Comment 8 Timur 2022-04-05 08:19:25 UTC
(In reply to Roman Kuznetsov from comment #5)
> I see 100% CPU loading (in oldest and in master builds in 7-4 bisect repo)
> but I couldn't get the LO's hanging/crash
> 
> I need some clear steps...

You can limit CPU using https://github.com/lowleveldesign/process-governor.
If there was a time when CPU wasn't that high. Seems in 7.3 not in 7.4.
Comment 9 Telesto 2022-04-05 09:10:59 UTC
There plenty of CPU cycles with older versions.. it takes 60 seconds until the CPU usage drops.. with 7.4 never stops.. 

So this more or less a bibisect hell, a pre-existing issue has become even more problematic

Checked:
Version: 7.2.1.0.0+ (x64) / LibreOffice Community
Build ID: 8fdbb8aed1b48734a717d5f98ada566de7204605
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

Versie: 4.4.7.2 
Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600
Locale: nl_NL
Comment 10 Timur 2022-04-05 09:21:50 UTC Comment hidden (obsolete)
Comment 11 Julien Nabet 2022-04-06 18:31:57 UTC
On pc Debian x86-64 with master sources updated today, I could reproduce this.
I got different types of logs first (let's say 20secs), eg:
warn:sw.core:187945:187945:sw/source/core/doc/textboxhelper.cxx:1184: SwTextBoxHelper::syncFlyFrameAttr: The anchor of the shape different from the textframe!
warn:legacy.osl:187945:187945:sw/source/core/text/frmform.cxx:1217: SwTextFrame::FormatLine: line height is zero
warn:sw.core:187945:187945:sw/source/core/doc/textboxhelper.cxx:1184: SwTextBoxHelper::syncFlyFrameAttr: The anchor of the shape different from the textframe!
warn:sw.core:187945:187945:sw/source/core/doc/textboxhelper.cxx:1184: SwTextBoxHelper::syncFlyFrameAttr: The anchor of the shape different from the textframe!
warn:sw.core:187945:187945:sw/source/core/doc/textboxhelper.cxx:1184: SwTextBoxHelper::syncFlyFrameAttr: The anchor of the shape different from the textframe!
warn:sw.core:187945:187945:sw/source/core/doc/textboxhelper.cxx:1184: SwTextBoxHelper::syncFlyFrameAttr: The anchor of the shape different from the textframe!
warn:sw.core:187945:187945:sw/source/core/view/vdraw.cxx:246: Trying to move anchor from invalid page - fix layouting!
warn:sw.core:187945:187945:sw/source/core/view/vdraw.cxx:246: Trying to move anchor from invalid page - fix layouting!
warn:sw.core:187945:187945:sw/source/core/doc/textboxhelper.cxx:1184: SwTextBoxHelper::syncFlyFrameAttr: The anchor of the shape different from the textframe!
warn:sw.core:187945:187945:sw/source/core/doc/textboxhelper.cxx:1184: SwTextBoxHelper::syncFlyFrameAttr: The anchor of the shape different from the textframe!
warn:sw.core:187945:187945:sw/source/core/view/vdraw.cxx:246: Trying to move anchor from invalid page - fix layouting!
warn:sw.core:187945:187945:sw/source/core/view/vdraw.cxx:246: Trying to move anchor from invalid page - fix layouting!

then the never ending loop:
warn:legacy.osl:187945:187945:sw/source/core/layout/objectformatter.cxx:326: LoopControl in SwObjectFormatter::FormatObj_: Stage 3!!!


Michael/Miklos: I know it's no news layout mechanism is quite complex, any idea about at least a bandaid here?
Comment 12 Miklos Vajna 2022-04-07 06:39:24 UTC
As you say, workarounds in this area are not a good idea, always good to understand the root cause.

I'm confused: the bug title says this is a regression, but then this is not bisected. Is that really not possible? Because then we could understand how this started to be a problem.
Comment 13 Telesto 2022-04-08 07:52:41 UTC
This
warn:legacy.osl:187945:187945:sw/source/core/layout/objectformatter.cxx:326: LoopControl in SwObjectFormatter::FormatObj_: Stage 3!!!

also to be seen with

1. Open attachment 159319 [details]

However I do observe it with
Version: 7.3.0.0.alpha1+ (x64) / LibreOffice Community
Build ID: 7b0aabe71d2455f6f643553a07f1056935cf190f
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

but not with
Version: 7.2.1.0.0+ (x64) / LibreOffice Community
Build ID: 8fdbb8aed1b48734a717d5f98ada566de7204605
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 14 Telesto 2022-04-08 08:44:10 UTC Comment hidden (obsolete)
Comment 15 Telesto 2022-04-08 08:45:19 UTC Comment hidden (obsolete)
Comment 16 Attila Bakos (NISZ) 2022-04-08 09:21:30 UTC
(In reply to Telesto from comment #14)
> Created attachment 179406 [details]
> Bibisect log
> 
> I bibisected the loop in comment 13 to
> 
> author	Attila Bakos (NISZ) <bakos.attilakaroly@nisz.hu>	2021-11-03 15:39:32
> +0100
> committer	László Németh <nemeth@numbertext.org>	2021-11-24 11:51:07 +0100
> commit eabcfb3f18a6944d9ad89cecd3eb3ca7a2259cf3 (patch)
> tree d1c66ab6056a467e3fc07bdbf6f07e179cb9e678
> parent becd76743fd7a3ae84404f26b1afb60b923cabb2 (diff)
> tdf#129183 sw: textboxes in group shapes - part 3
> Grouping/ungrouping nested groups works now.
> 
> Manual test:
> 
> 1.  Insert Shape.
> 2.  Right-click on selected shape, Add Text Box (and some text).
> 3.  Insert a new shape.
> 4.  Select and group the two shapes.
> 3.  Insert a third shape.
> 4.  Select and group the shape and the previously grouped shapes.
> 
> The text box remains in the nested shape group.
> 
> Details:
> 
> 1) tdf#144271 memory leak of SwTextBoxHelper, by replacing the
> textbox structure vector with std::unordered map, and rethinking
> of the ownership of the objects. If a SwFrameFormat dies, and that
> is a FLYFRMFMT, it will be deleted from the textbox node and the
> FrameFormat table in the doc too, and the drawing will be stay as
> it was before. If the dying format is a drawing, all the textboxes,
> and the node will be deleted.
> 
> 2) Introducing the new UNO property TextBoxContent, which is needed
> for writerfilter/xmloff later to set a new textbox for the shape
> via UNO.
> 
> 3) Missing parameters are present now for syncing the textbox
> parameters.
> 
> 4) Introducing a new function namely the handleGroupTextBox() to
> do the tasks simply with all textboxes in a group shape.
> This can handle nested groups as well (group in a group).
> 
> Known issues: now copy of nested group objects is implemented
> but not enabled, because it causes an assert.
> 
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=eabcfb3f18a6944d9ad89cecd3eb3ca7a2259cf3
> 
> ----
> Deleting the Drawing object in the document - mentioned in comment 13 -
> solves the looping

Notice: https://gerrit.libreoffice.org/c/core/+/125977
Comment 17 Telesto 2022-04-08 10:19:03 UTC
Created attachment 179407 [details]
Bibisect log

The problem got re-introduced after revert with:
author	Attila Bakos (NISZ) <bakos.attilakaroly@nisz.hu>	2022-01-11 12:09:46 +0100
committer	László Németh <nemeth@numbertext.org>	2022-02-02 14:20:55 +0100
commit 3b0a0e70cb67fc2e1f9999d2e8cbb9cfcd8c670e (patch)
tree fbb5c150d55247c9a89b5fe832a41f2fed0be163
parent 8165c629be4e70ea188f3ccf2b8e913feec75da1 (diff)
Related tdf#66039 DOCX import: fix Z-order of group shapes
A missing function resulted covered textboxes which weren't
visible in group shapes.

Follow-up to 121cbc250b36290f0f8c7265fea57256dad69553
"tdf#66039 DOCX: import textboxes (with tables, images etc.)
in group shapes".
Comment 18 Attila Bakos (NISZ) 2022-04-08 10:30:38 UTC Comment hidden (obsolete)
Comment 19 Telesto 2022-04-08 10:39:29 UTC
(In reply to Attila Bakos (NISZ) from comment #18)
> so strange, in this ticket the earliest version is the 7.3 and that patch is
> in only 7.4...

That's me being wrong :-(. 

Comment 0 and comment 8 are right:
> The attached file opens fine in 7.2 and 7.3. However, in LO 7.4 it enters
> some sort of infinite loop and LO stops responds
Comment 20 Attila Bakos (NISZ) 2022-04-08 10:45:23 UTC Comment hidden (obsolete)
Comment 21 Attila Bakos (NISZ) 2022-04-08 10:50:30 UTC Comment hidden (obsolete)
Comment 22 Attila Bakos (NISZ) 2022-04-08 10:53:27 UTC Comment hidden (obsolete)
Comment 23 Telesto 2022-04-08 11:35:32 UTC
(In reply to Attila Bakos (NISZ) from comment #22)
> Created attachment 179409 [details]
> Works fine at me

Well the document opens fine and seems responsive but keeps utilizing a single CPU core. Take a look at Task manager

-----

Same for attachment 159319 [details], which will freeze also freeze after CTRL+A CTRL+X CTRL+V


Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: efe854bf9b6daff3d0ecf6e3d04bd9a50bfaa3f3
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL Jumbo
Comment 24 Attila Bakos (NISZ) 2022-04-08 11:46:08 UTC Comment hidden (obsolete)
Comment 25 Attila Bakos (NISZ) 2022-04-08 11:46:08 UTC
indeed. okey, i will take a look.
Comment 26 Timur 2022-04-08 14:28:08 UTC
(In reply to Timur from comment #10)
> Test cannot be done simply with OOO_EXIT_POST_STARTUP=1, rather open and
> wait for CPU time, I used 75 to exit or timeout later.
> Seems to me that 7.3 master is good and 7.4 oldest and master are bad. 

7.3 oldest and master don't have high CPU but longer hangup after 120-130 secs. 
7.4 oldest had high CPU that blocks earlier. Then sha: 6a4e8f72d28dd51f504528df3f3b264bd0c88fbc was back to longer hangup (as found by Telesto bibisect). But later it went from longer hangup to high CPU, so master still has it. 

In Linux it can be seen with https://github.com/pshved/timeout. But somehow it's not consistent in bibisect.
Comment 27 Timur 2022-04-11 07:43:20 UTC
(In reply to Timur from comment #26)
> 7.4 oldest had high CPU that blocks earlier.
> Then sha:6a4e8f72d28dd51f504528df3f3b264bd0c88fbc was back to longer hangup. 
> But later it went from longer hangup to high CPU, so master still has it. 

That's sha:3b0a0e70cb67fc2e1f9999d2e8cbb9cfcd8c670e. 
author	Attila Bakos (NISZ) <bakos.attilakaroly@nisz.hu>
Related tdf#66039 DOCX import: fix Z-order of group shapes
Comment 28 Attila Bakos (NISZ) 2022-05-17 13:40:27 UTC
patch here: https://gerrit.libreoffice.org/c/core/+/134480
Comment 29 Rafael Lima 2022-05-18 02:20:57 UTC
(In reply to Attila Bakos (NISZ) from comment #28)
> patch here: https://gerrit.libreoffice.org/c/core/+/134480

Hi Atilla, I cherry-picked your patch and tested it. The sample file no longer hangs and it seems fine now.

Thanks for the fix.
Comment 30 Attila Bakos (NISZ) 2022-05-18 11:32:57 UTC
You are welcome. :)
Comment 31 Commit Notification 2022-05-27 07:39:11 UTC
Attila Bakos (NISZ) committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/182d2a47a2b4ed0affdc828a534c1659cc2e926d

tdf#148365 sw: fix freezing with FrameIsAutomaticHeight

It will be available in 7.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 32 Julien Nabet 2022-05-27 21:46:24 UTC
On pc Debian x86-64 with master sources updated today + gen rendering (since because another bug I can launch Writer specifically only with this rendering), I don't reproduce the infinite loop anymore.
Thank you Attila!
Comment 33 Commit Notification 2022-05-30 09:17:48 UTC
Attila Bakos (NISZ) committed a patch related to this issue.
It has been pushed to "libreoffice-7-3":

https://git.libreoffice.org/core/commit/906151f18771418ee899f59fc98c774b07dadf16

tdf#148365 sw: fix freezing with FrameIsAutomaticHeight

It will be available in 7.3.5.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.