Steps: 1. Open attachment 121586 [details] Observed behavior: Libreoffice hangs opening the document Reproduced in Version: 5.3.0.0.alpha1+ Build ID: 4ebf1ea7cb66fc3e6b94cd38dd233aaead69f3d5 CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; Layout Engine: old; Locale: ca-ES (ca_ES.UTF-8); Calc: group but not in Version: 5.0.0.0.alpha1+ Build ID: 0db96caf0fcce09b87621c11b584a6d81cc7df86 Locale: ca-ES (ca_ES.UTF-8)
Confirmed with 5.1.0.3 / Windows 7. Loads fine with 5.0.6.3.
Hello Xisco, *, I can confirm your bug with OS: Debian Testing AMD64 LO: Version: 5.3.0.0.beta1 Build ID: 690f553ecb3efd19143acbf01f3af4e289e94536 CPU Threads: 4; OS Version: Linux 4.5; UI Render: default; VCL: gtk2; Layout Engine: new; Locale: de-DE (de_DE.UTF-8); Calc: group back to LO: Version: 5.1.0.3 Build-ID: 5e3e00a007d9b3b6efb6797a8b8e57b51ab1f737 CPU Threads: 4; OS Version: Linux 4.5; UI Render: default; Gebietsschema: de-DE (de_DE.UTF-8) but not back to LO: Version: 5.0.6.3 Build-ID: 490fc03b25318460cfc54456516ea2519c11d1aa Gebietsschema: de-DE (de_DE.UTF-8) (all parallel installed, following the instructions from https://wiki.documentfoundation.org/Installing_in_parallel/Linux) so changing the "Version" to 5.1.0.3. I will attach a backtrace and strace afterwards ... ;) HTH Thomas.
Created attachment 129010 [details] "soffice --backtrace" output
Created attachment 129011 [details] bzip2'ed "soffice --strace" output
This seems to have begun at the below commit. Adding Cc: to Mike Kaganski ; Could you possibly take a look at this one? Thanks author Mike Kaganski <mike.kaganski@collabora.com> 2015-11-21 06:18:38 (GMT) committer Michael Meeks <michael.meeks@collabora.com> 2015-11-23 11:32:08 (GMT) commit d59ef5b2ddb9249905fecf941be6ec83251d12de (patch) tree fc03b5080f7795fad15a79fac66d2dfc9171a7f5 parent 0cda1453a0e24e9ad6884a1345e4514a86900346 (diff) tdf#60351: Use Wrap Polygon also for PROP_SIZE_PIXEL a40fcb0eb3a66fe00a26ee0409c225b4c716e0d8 is the first bad commit commit a40fcb0eb3a66fe00a26ee0409c225b4c716e0d8 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Mon Nov 23 10:19:22 2015 -0800 source d59ef5b2ddb9249905fecf941be6ec83251d12de git bisect log # bad: [05d11632892a322664fb52bac90b2598b7fb7544] source 5616d22b57a9a5e57d545e912e029162a230829b # good: [c1efd324c6ad448ac9edb030dc9738b9e6899e4d] source ab465b90f6c6da5595393a0ba73f33a1e71a2b65 git bisect start 'origin/master' 'oldest' # good: [97526ab777da7e58ce283c05498262ecdd4d6f7f] source 4ea70f87f7a2b61eda6e5ab1f48debf6fcfadc1f git bisect good 97526ab777da7e58ce283c05498262ecdd4d6f7f # good: [86fee7ded76d9c2756ccab6aef160a2d7fab0ab6] source 1b62841b1859ae3443e2bf1ebe99ec3d6afb6cc2 git bisect good 86fee7ded76d9c2756ccab6aef160a2d7fab0ab6 # good: [11864a7db429a57aeea021e0b3f1fb1412282d32] source e5b721a14c1c8e5261a70588b30353cbb5bd55c6 git bisect good 11864a7db429a57aeea021e0b3f1fb1412282d32 # good: [7d52a87c0aa24498584ec522705cfae3a3a5a038] source 479df22d0b4b0e0393fcf621e7380b38415bcef8 git bisect good 7d52a87c0aa24498584ec522705cfae3a3a5a038 # bad: [bea538a879f50238f4c9c6f05e3d7390db9d76c7] source 7289a140fc68dc898ba2b2357cc960968195f236 git bisect bad bea538a879f50238f4c9c6f05e3d7390db9d76c7 # good: [ad146f48b7f50d159d5b96f1c118cdb8412a98b8] source 91cbbb7797f048834b51690e9fab60aa778b1e44 git bisect good ad146f48b7f50d159d5b96f1c118cdb8412a98b8 # bad: [773530329ceb1603b45cab2fadb112d5f2edbc9e] source 6525d1663f8d03e2c28e626fadc2e3e848798224 git bisect bad 773530329ceb1603b45cab2fadb112d5f2edbc9e # bad: [1ab72c9b7bd963ca1e9fa260887b0a82bc57a704] source 9ca49c1b95bad0055ffc9185249cec0a27376dbc git bisect bad 1ab72c9b7bd963ca1e9fa260887b0a82bc57a704 # bad: [84fb727f09941a0c7637637bf733b770490c11c0] source f1592d3821a2ab69d2ddd27095696a39082bc24d git bisect bad 84fb727f09941a0c7637637bf733b770490c11c0 # good: [98c6656c9568b9ef64bd61cbee930d127d07ba29] source bc8c158ec6ba24b1ecaf5d3d57deb65ef0670f6c git bisect good 98c6656c9568b9ef64bd61cbee930d127d07ba29 # bad: [a40fcb0eb3a66fe00a26ee0409c225b4c716e0d8] source d59ef5b2ddb9249905fecf941be6ec83251d12de git bisect bad a40fcb0eb3a66fe00a26ee0409c225b4c716e0d8 # good: [0eaad9f01f2e5dc60d0fe3cd98013d769014cd9a] source e2c03fde5807b9a3a57321ff9396c3dd76ab4dcf git bisect good 0eaad9f01f2e5dc60d0fe3cd98013d769014cd9a # good: [9567fe102c2d87e17756b0135eba8e73da8e84b7] source 0cda1453a0e24e9ad6884a1345e4514a86900346 git bisect good 9567fe102c2d87e17756b0135eba8e73da8e84b7 # first bad commit: [a40fcb0eb3a66fe00a26ee0409c225b4c716e0d8] source d59ef5b2ddb9249905fecf941be6ec83251d12de
*** Bug 104553 has been marked as a duplicate of this bug. ***
Again, this is not caused by the identified patch, but is exactly the same as in its parent bug 96751. That bug happens like that: when its bugdoc is open, the image in it has wrong wrap contour, and thus is placed incorrectly. The wrong placement happens to avoid a bug with layout looping. But when user manually fixes the contour problem (by turning off wrapping), and image is trying to go to proper place, the layout loop happens. Now that the image wrap contour import was fixed, it is imported correctly from the start, so the loop fires immediately. So, this isn't a new bug and not a regression, but just change in time of occurrence of original bug. *** This bug has been marked as a duplicate of bug 96751 ***