Bug 113830 - FILEOPEN DOCX: infinite loop at import time
Summary: FILEOPEN DOCX: infinite loop at import time
Status: RESOLVED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.3.0.0.alpha0+
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, filter:docx, haveBacktrace, perf, regression
Depends on:
Blocks:
 
Reported: 2017-11-14 15:13 UTC by Xisco Faulí
Modified: 2017-11-15 12:24 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
GDB trace of hang with master (35.83 KB, text/plain)
2017-11-14 15:22 UTC, Buovjaga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Xisco Faulí 2017-11-14 15:13:02 UTC
Steps to reproduce:
1. Open attachment 121586 [details] from bug 96751

Observed behaviour: The document takes forever to open.

Reproduced in

Version: 6.0.0.0.alpha1+
Build ID: 9050854c35c389466923f0224a36572d36cd471a
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; 
Locale: th-TH (ca_ES.UTF-8); Calc: group

and

Version: 5.2.0.0.alpha1+
Build ID: 5b168b3fa568e48e795234dc5fa454bf24c9805e
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; 
Locale: ca-ES (ca_ES.UTF-8)

real	37m32,767s
user	37m20,792s
sys	0m0,996s

(I killed it)

but not in

Version: 5.0.0.0.alpha1+
Build ID: 0db96caf0fcce09b87621c11b584a6d81cc7df86
Locale: ca-ES (ca_ES.UTF-8)

real	0m1,535s
user	0m1,244s
sys	0m0,096s
Comment 1 Xisco Faulí 2017-11-14 15:13:54 UTC
[Bug found by office-interoperability-tools]
Comment 2 Buovjaga 2017-11-14 15:22:23 UTC
Created attachment 137752 [details]
GDB trace of hang with master

Repro.

Trace seems to have useful info.

Arch Linux 64-bit, KDE Plasma 5
Version: 6.0.0.0.alpha1+
Build ID: d73225119476de1826f648acca9e93bf6797e813
CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on November 12th 2017
Comment 4 Xisco Faulí 2017-11-15 11:30:41 UTC
Regression introduced by: (reverted locally)

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
Since commit 2b5bf2f1c57d6585ec898c4c44a74c5b47f09ab9
"graphic import improved" from 2006-11-20 by Oliver Specht,
there is an unused code reading pixel size (PROP_SIZE_PIXEL) of an
image in a part of GraphicImport::createGraphicObject() that imports
the wrap polygon.
When there's no PROP_SIZE100th_M_M in graphic, the imported wrap
polygon was simply dropped, and then automatic contour was generated
for graphic. Now we import contour correctly in this case.

Also, as paragraph background overlaps non-opaque graphics,
we need to set opaque to true regardless of behindDoc value of
wp:anchor.

Adding Cc: to Mike Kaganski
Comment 5 Mike Kaganski 2017-11-15 11:51:35 UTC
Not a regression from that commit; it's just that changed wrapping of some object shifted things in a document; layout calculations changed accordingly, and some corner case had surfaced.
Comment 6 Mike Kaganski 2017-11-15 12:11:40 UTC
Ah! I see the reason. I already explained that in bug 96751 comments. So the image in bugdoc should not have had incorrect wrapping in the first place; it got it as result of a bug 60351, and the wrapping avoided the infinite loop; then reporter tried to get rid of it, and infinite loop started. Now that bug 60351 is fixed, the image gets correct wrap polygon (equal to image size; the same as selecting Format > Wrap > None) at import time, so it's just a shift in the bug's appearance time.

Adding Caolan, as it's still the same problem as in bug 96751.
Comment 7 Mike Kaganski 2017-11-15 12:17:39 UTC
Xisco: wasn't you who filed tdf#104166? :)
Comment 8 Xisco Faulí 2017-11-15 12:24:16 UTC
(In reply to Mike Kaganski from comment #7)
> Xisco: wasn't you who filed tdf#104166? :)

oh shit, actually, it's the same file. I look for the hash id in Bugzilla but I couldn't find the other report ( I didn't look for RESOLVED bugs).
I'm really sorry for the noise. I guess we can close it as INVALID as they are exactly the same.