Bug 104166 - FILEOPEN: DOCX: Libreoffice hangs at importing time
Summary: FILEOPEN: DOCX: Libreoffice hangs at importing time
Status: RESOLVED DUPLICATE of bug 96751
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Hardware: All All
: high critical
Assignee: Not Assigned
Keywords: bibisected, bisected, filter:docx, haveBacktrace, perf, regression
Depends on:
Blocks: DOCX-Opening
  Show dependency treegraph
Reported: 2016-11-25 16:20 UTC by Xisco Faulí
Modified: 2017-11-15 12:17 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

"soffice --backtrace" output (32.25 KB, text/x-log)
2016-11-25 16:48 UTC, Thomas Hackert
bzip2'ed "soffice --strace" output (311.37 KB, application/x-bzip)
2016-11-25 16:49 UTC, Thomas Hackert

Note You need to log in before you can comment on or make changes to this bug.
Description Xisco Faulí 2016-11-25 16:20:05 UTC
1. Open attachment 121586 [details]

Observed behavior: Libreoffice hangs opening the document

Reproduced in

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

Build ID: 0db96caf0fcce09b87621c11b584a6d81cc7df86
Locale: ca-ES (ca_ES.UTF-8)
Comment 1 Aron Budea 2016-11-25 16:40:15 UTC
Confirmed with / Windows 7.
Loads fine with
Comment 2 Thomas Hackert 2016-11-25 16:47:12 UTC
Hello Xisco, *,
I can confirm your bug with

OS: Debian Testing AMD64
LO: Version:
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:
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:
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 I will attach a backtrace and strace afterwards ... ;)
Comment 3 Thomas Hackert 2016-11-25 16:48:06 UTC
Created attachment 129010 [details]
"soffice --backtrace" output
Comment 4 Thomas Hackert 2016-11-25 16:49:09 UTC
Created attachment 129011 [details]
bzip2'ed "soffice --strace" output
Comment 5 raal 2016-11-26 20:45:18 UTC
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
Comment 6 Mike Kaganski 2016-12-19 20:21:59 UTC
*** Bug 104553 has been marked as a duplicate of this bug. ***
Comment 7 Mike Kaganski 2016-12-19 20:45:10 UTC
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 ***