Description: Looping Louie isn't always aborted by LoopControl_2 in Interrupt formatting in SwLayAction::InternalAction Steps to Reproduce: 1. Open the attached file (in single page view) (it's file from bug 154863 with 3 footnotes added) 2. Move image of second last page to left top corner (as in screencast) 3. Freeze: Looping Louie stage 1-3 4. With luck: LoopControl_2 in Interrupt formatting in SwLayAction::InternalAction 5. If case 4 occurs: the whole looping starts again if you scroll up and down again. With luck LoopControl_2. With bad luck endless loop Actual Results: * Loop control doesn't work reliably (possibly because of debugger attached?) * The loop can easily start again simply by scrolling past the problematic page again without any modification Expected Results: Ideally a more robust loop control. Reproducible: Always User Profile Reset: No Additional Info: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 4d381b54d1c598c181b4a21a8bf0db86eb4668d1 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 threaded
Created attachment 192407 [details] Sample
Created attachment 192408 [details] Screencast
icuuc73.dll!ubidi_getClass_73+0x11e icuuc73.dll!u_charDirection_73+0x11 mergedlo.dll!SalLayoutGlyphsCache::self+0x45a mergedlo.dll!SalLayoutGlyphsCache::GetLayoutGlyphs+0x594 swlo.dll!sw::MetaFieldManager::getDocumentProperties+0x55c0 swlo.dll!sw::MetaFieldManager::getDocumentProperties+0x7e26 swlo.dll!SwTextFormatColl::IsInSwFntCache+0x42f5 swlo.dll!SwViewOption::IsShowChangesInMargin2+0x4fc4 swlo.dll!SwViewOption::IsShowChangesInMargin2+0x2071 swlo.dll!SfxEnumItem<enum SwLineBreakClear>::GetValue+0xcb2 swlo.dll!SwTextFrame::GetAdditionalFirstLineOffset+0x2aa6 swlo.dll!SwTextFrame::GetAdditionalFirstLineOffset+0x724c swlo.dll!SwTextFrame::FormatLine+0x11a swlo.dll!SwTextFrame::Format_+0xecd swlo.dll!SwTextFrame::FormatImpl+0x310 swlo.dll!SwTextFrame::Format+0xaf7 swlo.dll!SwContentFrame::MakeAll+0xdd7 swlo.dll!SwFrame::OptPrepareMake+0x169 swlo.dll!SwPageFrame::PrepareFooter+0x6875 swlo.dll!SwPageFrame::PrepareFooter+0x57fa swlo.dll!SwPageFrame::PrepareFooter+0x2103 swlo.dll!SwViewShell::ImplEndAction+0x336 swlo.dll!SwFEShell::EndDrag+0x144 swlo.dll!SwWrtShell::UpdateLayoutFrame+0x17 swlo.dll!SwEditWin::MouseButtonUp+0xee4 mergedlo.dll!ImplCallPreNotify+0x22d6 mergedlo.dll!vcl::Window::ImplAsyncFocusHdl+0xf9a mergedlo.dll!vcl::Window::ImplAsyncFocusHdl+0x1d64 mergedlo.dll!SalFrame::CallCallback+0x1c
The source file original (attachment 192273 [details]) doesn't have the issue. BT (no-debug) to some extent suggest it being 'caused' by footer. Or footer making layout more prone to the freeze.
Also in Version: 7.0.7.0.0+ (x64) Build ID: 626ea4e62a3e5005fe9825923a1c0c5bdb61cc08 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL freezes with long time. Did finish, 1 scroll wheel tick it looping again in Version: 6.1.6.3 Build ID: 5896ab1714085361c45cf540f76f60673dd96a72 CPU threads: 4; OS: Windows 6.3; UI render: default; Locale: nl-NL (nl_NL); Calc: CL and in Version: 5.4.0.3 Build ID: 7556cbc6811c9d992f4064ab9287069087d7f62c CPU threads: 4; OS: Windows 6.2; UI render: default; Locale: nl-NL (nl_NL); Calc: CL and in (new layout engine) Versie: 5.3.5.2 Build ID: 50d9bf2b0a79cdb85a3814b592608037a682059d CPU-threads: 4; Besturingssysteem:Windows 6.2; UI-render: GL; Layout Engine: new; Locale: nl-NL (nl_NL); Calc: group ----- freezes for 30 seconds, it's OK afterwards Versie: 5.3.5.2 (old layout engine) Build ID: 50d9bf2b0a79cdb85a3814b592608037a682059d CPU-threads: 4; Besturingssysteem:Windows 6.2; UI-render: GL; Layout Engine: old; Locale: nl-NL (nl_NL); Calc: CL and in Version: 5.2.5.0.0+ Build ID: a4d4fbeb623013f6377b30711ceedb38ea4b49f8 CPU Threads: 4; OS Version: Windows 6.2; UI Render: GL; TinderBox: Win-x86@62-merge-TDF, Branch:libreoffice-5-2, Time: 2016-12-24_14:43:55 Locale: nl-NL (nl_NL); Calc: CL and in Version: 5.1.0.0.alpha1+ Build ID: 49c2b9808df8a6b197dec666dfc0cda6321a4306 Threads 4; Ver: Windows 6.29; Render: GL;
On Linux, I even got: - freeze for a few seconds - image ends up at bottom of previous page - zoom down and up: freeze again, then crashed. https://crashreport.libreoffice.org/stats/crash_details/88243c62-f73d-4938-8cb3-8661ca8bf290 Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1cda27cf69054b006aa1b16cab8f56339274588b CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Same issue if saved as ODT before. As in comment 4, no issue in version with no footnote.
(In reply to Stéphane Guillou (stragu) from comment #6) Do you mean: it still crashing with master, or only with 7.6.4. This file shouldn't cause a crash, based the fix at bug 154863. FWIW: I'm unable to make it crash with master on Windows...
(In reply to Stéphane Guillou (stragu) from comment #6) > - zoom down and up: freeze again, then crashed. this should be "_scroll_ down and up" (In reply to Telesto from comment #7) > Do you mean: it still crashing with master, or only with 7.6.4. This file > shouldn't cause a crash, based the fix at bug 154863. > FWIW: I'm unable to make it crash with master on Windows... Hm I think you're right, I might have mistakenly tested with 24.2 instead of the master build... I have not managed to crash it again on a current master build, but it is constantly freezing. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ef9e1116d1100af50d7b74dcee5155c81b7b50fb CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded I have tested OOo 3.3 but the layout is so different that I can hardly use the same steps. (number of pages constantly goes up on fileopen; scrolling the document hangs)