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
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
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
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
@Roman, could you please try to bisect this on your end ?
(In reply to Xisco Faulí from comment #4) > @Roman, could you please try to bisect this on your end ? 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...
> 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.
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
(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.
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
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. So bibisect is not possible for me, although I have a script to do it.
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?
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.
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
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
Adding CC: to Attila Bakos
(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
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".
(In reply to Telesto from comment #17) > 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". so strange, in this ticket the earliest version is the 7.3 and that patch is in only 7.4...
(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
(In reply to Telesto from comment #19) > (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 No problem :) okay it will check it.
(In reply to Attila Bakos (NISZ) from comment #20) > (In reply to Telesto from comment #19) > > (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 > > No problem :) okay it will check it. Works fine at me with: Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 4e8d6ccf97e29e5ea14e0d074074606f12040f36 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: hu-HU Calc: CL Is that possible it have been fixed so recently?
Created attachment 179409 [details] Works fine at me
(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
indeed. okey, i will take a look.
(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.
(In reply to Timur from comment #26) > 7.4 oldest had high CPU that blocks earlier. > Then 6a4e8f72d28dd51f504528df3f3b264bd0c88fbc was back to longer hangup. > But later it went from longer hangup to high CPU, so master still has it. That's 3b0a0e70cb67fc2e1f9999d2e8cbb9cfcd8c670e. author Attila Bakos (NISZ) <bakos.attilakaroly@nisz.hu> Related tdf#66039 DOCX import: fix Z-order of group shapes
patch here: https://gerrit.libreoffice.org/c/core/+/134480
(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.
You are welcome. :)
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.
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!
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.