Bug 134417 - Layout loop/freeze after changing anchor from to paragraph to to character
Summary: Layout loop/freeze after changing anchor from to paragraph to to character
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: high critical
Assignee: Not Assigned
Keywords: bibisected, regression
Depends on:
Blocks: Anchor-and-Text-Wrap CPU-AT-100%
  Show dependency treegraph
Reported: 2020-06-30 08:31 UTC by Telesto
Modified: 2022-06-19 19:13 UTC (History)
1 user (show)

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

Example file (1.01 MB, application/vnd.oasis.opendocument.text)
2020-06-30 08:32 UTC, Telesto
Bibisect log (3.08 KB, text/plain)
2020-06-30 10:21 UTC, Telesto
Bibisect log crash (4.28 KB, text/plain)
2020-06-30 10:44 UTC, Telesto
Next example (1.01 MB, application/vnd.oasis.opendocument.text)
2020-07-01 19:18 UTC, Telesto

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-06-30 08:31:43 UTC
Layout loop/freeze after changing anchor from to paragraph to to character

Steps to Reproduce:
1. Open the attached file
2. Right click the first image on page 2, top image ("afbeelding 99)
3. Change the anchor for to paragraph to character

Actual Results:

Expected Results:
No freeze

Reproducible: Always

User Profile Reset: No

Additional Info:
Version: (x64)
Build ID: 006c65bbd472cb1d7d44e095714e28190b76be0d
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 1 Telesto 2020-06-30 08:32:03 UTC
Created attachment 162541 [details]
Example file
Comment 2 Telesto 2020-06-30 08:34:27 UTC
Found in
Build ID: c30963b8b4bbbe42a24b97aafa161eff9d7ccdd4
CPU threads: 4; OS: Windows 6.3; UI render: default; 
Locale: nl-NL (nl_NL); Calc: CL

but not in
Build ID: 3d5603e1122f0f102b62521720ab13a38a4e0eb0
CPU Threads: 4; Versie besturingssysteem:Windows 6.2; UI Render: standaard; 
Locale: nl-NL (nl_NL); Calc: CL
Comment 3 Telesto 2020-06-30 08:37:04 UTC
Also in
Build ID: 50d9bf2b0a79cdb85a3814b592608037a682059d
CPU-threads: 4; Besturingssysteem:Windows 6.2; UI-render: standaard; Layout Engine: old; 
Locale: nl-NL (nl_NL); Calc: CL
Comment 4 Telesto 2020-06-30 09:38:51 UTC
Also in 5.2 (I was wrong)
Also in 5.1
Not in 5.0

However it crashes when moving the image again (that does not happen with
Comment 5 Telesto 2020-06-30 10:21:54 UTC
Created attachment 162546 [details]
Bibisect log

Bibisected to 2657d8d66ffd95013a4913d929ae452186be8be7 is the first bad commit
commit 2657d8d66ffd95013a4913d929ae452186be8be7
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Fri Sep 4 17:35:26 2015 -0700

    source f7bc163ca4f643b6f046892de6d99ec8049b6955

    source f7bc163ca4f643b6f046892de6d99ec8049b6955
    source c82672717b5f355bc406f0b5d78b5d6c5b9dd621
    source 7289f291fe6a43487c7edeb2b14169cc3a0d6694
    source 2b8e62f7b6e0a45a9ff1ec530b2e941f3fbcf1a0

For the record.. I bibisected the point, where the looping - so never finished - previously it did stop (after 8 seconds of attempts).. the previous state was not stable either.. touch the image again.. crash
Comment 6 Telesto 2020-06-30 10:44:39 UTC
Created attachment 162547 [details]
Bibisect log crash

Crashing at second drag started here (not sure if relevant anymore)
# possible first bad commit: [08518721ea5688427dd2f3f02682782dc5aa513a] source b951771244d511c140a7c84181a1e160d9ef97c1
# possible first bad commit: [4b8747be032833fc4c20d83f57cb1b17899144ec] source e4fab06d82299054ddd46c7d925d300cd3d0a17d
# possible first bad commit: [45bab4b78bb1725ee35071dabc89a411e5093a87] source 75155bcf07d296352162d0b963493b4ba0238cca
# possible first bad commit: [c7a8fc8ad2f441ca5f993c384db5955b96619e97] source 2633a2a34eb2e3c3de807ba0d9966c42330b6ff0
# possible first bad commit: [1a67d9871788c07ab2b3859145fa62a0aec9f4af] source fb69055c1b505ed09fb170093bab4ecd5bb3fdc7
# possible first bad commit: [289944c3cdfecb42472737a5d5b0704bfb29a125] source 6c02186ec0660c1fd4d1fd46b6d4ce97ff1178ec
Comment 7 Telesto 2020-07-01 19:18:05 UTC
Created attachment 162573 [details]
Next example

1. Open the attached file
4. CTRL+SHIFT+V -> Paste RTF -> And start waiting
Comment 8 Buovjaga 2021-01-11 07:50:16 UTC

Arch Linux 64-bit
Build ID: 8ac5b55ada3f408b8a6084a2e1811bbf4ee7ad51
CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: kf5
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 10 January 2021
Comment 9 Telesto 2021-01-11 20:35:43 UTC
(In reply to Buovjaga from comment #8)
My bibisect in comment 6 makes no sense .. can find any commit which explains the crash
Comment 10 sdc.blanco 2022-06-19 19:13:10 UTC
Additional information:

Small modifications that avoid crash/freeze:

1.  Change Vertical and Horizontal Position of "afbeelding99" to Entire Page, instead of "Entire Paragraph".  Now you can change anchor "to character" without crash.

2. Change anchor of "afbeelding100" to "to paragraph"  (both images move to first page), now you can change anchor of "afbeelding99" to "to character" without crash.

3. Drag "afbeelding100" downward with mouse (arrow keys do not work), it will move to the next page (after the "cat photo" (Afbeelding181)), because "afbeelding100" is anchored "to character", where the character is the cat photo (which is anchored "as character").  Now you can change the anchor of "afbeelding99" to "to character" without crash.

4.  Select the first three lines after the cat photo (starts with: consequat, vel illum dolore eu feugiat) and paste it in front of the photo.  Note that the text will move to the same page as "afbeelding99" and "afbeelding100".  Now you can change the anchor of "afbeelding99" to "to character" without crash.

In short -- the "test file" is a highly specialized (and highly unlikely) case where the cat photo is the first character of the paragraph to which it appears that both "afbeelding99" and "afbeelding100" are anchored.  

I have shown several different ways that one could "avoid" the crash -- though I cannot explain why the particular combination results in the crash.

Maybe it is a regression, I have no knowledge or opinion about that.  But even if it was -- is it worth keeping this ticket open for a configuration that is highly unlikely to be created in a normal use situation?  I would propose something like INVALID or INSUFFICIENTDATA