| Summary: | Writer stops responding with busy CPU after opening this document | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Luke Deller <luke> |
| Component: | Writer | Assignee: | Michael Stahl (allotropia) <michael.stahl> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | 79045_79045, kelemeng, michael.stahl, telesto |
| Priority: | high | Keywords: | bibisected, bisected, perf, regression |
| Version: | 6.2.5.2 release | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: | https://bugs.documentfoundation.org/show_bug.cgi?id=119109 | ||
| Whiteboard: | target:24.2.0 target:7.6.1 | ||
| Crash report or crash signature: | Regression By: | Michael Stahl | |
| Bug Depends on: | |||
| Bug Blocks: | 136524, 113510 | ||
| Attachments: | hang-lo.odt | ||
Bibisect 6.2 Linux: a120608f173727c80279991f7806c0dedcd859b3 is the first bad commit Date: Thu May 23 20:50:46 2019 +0200 source 72b52ba3c7bd3233ca3e721c3e3d69dd08246bdc previous 07642832e3d9c3d1648324ef40bff09bfde1f6e5 author Michael Stahl <Michael.Stahl@cib.de> 2019-05-22 17:39:15 +0200 committer Thorsten Behrens <Thorsten.Behrens@CIB.de> 2019-05-23 16:59:40 +0200 commit 72b52ba3c7bd3233ca3e721c3e3d69dd08246bdc (patch) tree 50989f5966f1d1c26a859b82df4bea3d7c9f9e40 parent 07642832e3d9c3d1648324ef40bff09bfde1f6e5 (diff) tdf#119109 sw: fix SwTableFrame follow chain formatting CC: Michael. Please see this. Thanks Timur! I opened this in the debugger with a local build LibreOfficeDev 7.2.0.0.alpha1 ec629c5ee22d02f99d66a5cf975ce239876b7f4d There is an infinite loop at the following location because pFrame->FindNext() is returning pFrame again: (gdb) frame #0 SwFrame::PrepareMake (this=0x55555aa58180, pRenderContext=0x55555ab5b3a0) at /home/deller/build/lo/sw/source/core/layout/calcmove.cxx:349 349 pFrame = pFrame->FindNext(); (gdb) bt #0 SwFrame::PrepareMake(OutputDevice*) (this=0x55555aa58180, pRenderContext=0x55555ab5b3a0) at /home/deller/build/lo/sw/source/core/layout/calcmove.cxx:349 #1 0x00007fffbe797bfe in SwFrame::Calc(OutputDevice*) const (this=0x55555aa58180, pRenderContext=0x55555ab5b3a0) at /home/deller/build/lo/sw/source/core/layout/trvlfrm.cxx:1792 #2 0x00007fffbe7018cd in SwLayAction::FormatLayoutTab(SwTabFrame*, bool) (this=0x7fffffff2000, pTab=0x55555aa58180, bAddRect=false) at /home/deller/build/lo/sw/source/core/layout/layact.cxx:1476 #3 0x00007fffbe7010fe in SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7fffffff2000, pRenderContext=0x55555ab5b3a0, pLay=0x55555aafa430, bAddRect=false) at /home/deller/build/lo/sw/source/core/layout/layact.cxx:1364 #4 0x00007fffbe70118e in SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7fffffff2000, pRenderContext=0x55555ab5b3a0, pLay=0x55555ab2be80, bAddRect=false) at /home/deller/build/lo/sw/source/core/layout/layact.cxx:1369 #5 0x00007fffbe6fe1e1 in SwLayAction::InternalAction(OutputDevice*) (this=0x7fffffff2000, pRenderContext=0x55555ab5b3a0) at /home/deller/build/lo/sw/source/core/layout/layact.cxx:528 #6 0x00007fffbe6fd6e9 in SwLayAction::Action(OutputDevice*) (this=0x7fffffff2000, pRenderContext=0x55555ab5b3a0) at /home/deller/build/lo/sw/source/core/layout/layact.cxx:341 #7 0x00007fffbe705255 in SwLayIdle::SwLayIdle(SwRootFrame*, SwViewShellImp*) (this=0x7fffffff20c0, pRt=0x55555a9eb420, pI=0x55555a9f0970) at /home/deller/build/lo/sw/source/core/layout/layact.cxx:2213 #8 0x00007fffbec3877e in SwViewShell::LayoutIdle() (this=0x55555ab44750) at /home/deller/build/lo/sw/source/core/view/viewsh.cxx:716 #9 0x00007fffbe3cdd9d in sw::DocumentTimerManager::DoIdleJobs(Timer*) (this=0x55555a80d210) at /home/deller/build/lo/sw/source/core/doc/DocumentTimerManager.cxx:177 ... The document here has an awkward construct on page 3 involving nested tables: there is an outer table with a header row, in which is embedded an inner table with all the real content which is longer than a page. I expect the author did not intend to have that outer table, indeed it is hard to notice it exists in the UI. Magic words for search: Adding CC: to Michael Stahl I confirm the attachment still hangs in: Version: 7.5.2.2 (X86_64) / LibreOffice Community Build ID: 53bb9681a964705cf672590721dbc85eb4d0c3a2 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/fcf6f5550cc7949e94dc74cbcd10a700a225e574 tdf#142694 sw: layout: fix infinite loop in SwFrame::PrepareMake() It will be available in 24.2.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. fixed on master Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/346cedd597bee1058bb8ebd0681faad9d8c2b203 tdf#142694 sw: layout: fix infinite loop in SwFrame::PrepareMake() It will be available in 7.6.1. 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. |
Created attachment 172661 [details] hang-lo.odt Opening the attached document "hang-lo.odt" in LibreOffice (version 6.2 or later) causes LibreOffice to become unresponsive, with 100% CPU utilization on one core. The first page of the document is displayed, but then the user interface stops responding and the application must be killed to recover. LibreOffice 6.1.6.3 can open the document fine.