Issue 101980 - OOo 3.1 freezes with 100% CPU on opening an odt file with fontwork objects
Summary: OOo 3.1 freezes with 100% CPU on opening an odt file with fontwork objects
Alias: None
Product: Writer
Classification: Application
Component: open-import (show other issues)
Version: OOo 3.1
Hardware: PC All
: P2 Trivial with 1 vote (vote)
Target Milestone: ---
Assignee: wolframgarten
QA Contact: issues@sw
Keywords: regression
Depends on:
Reported: 2009-05-16 09:35 UTC by jbf.faure
Modified: 2013-08-07 14:43 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

test file with fontwork objects (65.81 KB, application/vnd.oasis.opendocument.text)
2009-05-16 09:36 UTC, jbf.faure
no flags Details
file with only one fontwork object (9.23 KB, application/vnd.oasis.opendocument.text)
2009-05-16 09:51 UTC, jbf.faure
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description jbf.faure 2009-05-16 09:35:01 UTC
OOo 3.1 can't open attached odt file which contains fontwork objects.
On my ubuntu 8.04 native OOo 3.1 FR freezes with 100% CPU.
Problem has reproduced on MS-Windows Vista and MacOS.
Comment 1 jbf.faure 2009-05-16 09:36:17 UTC
Created attachment 62307 [details]
test file with fontwork objects
Comment 2 jbf.faure 2009-05-16 09:41:08 UTC
Complement : OOo 3.0.1 opens this file without problem.
Comment 3 jbf.faure 2009-05-16 09:50:04 UTC
In the first file, it seems that only one fontwork object causes the freeze.
The guilty fontwork object has been isolated in the following file using OOo 2.4.2

Comment 4 jbf.faure 2009-05-16 09:51:02 UTC
Created attachment 62308 [details]
file with only one fontwork object
Comment 5 michael.ruess 2009-05-18 13:24:21 UTC
MRU->OD: attached document contains some fontwork objects and graphics in a
table. This will lead to a loop in OOo 3.1. Did not loop in OOo 3.0.1.
After removing the fontwork objects, the document could be opened.
Disabling the "Anti-aliasing" did not help.
Comment 6 Oliver-Rainer Wittmann 2009-05-28 14:31:38 UTC
Investigation reveals that the calculation of the contour of the fontwork object
takes very very long. The internal variable <nSize> in method
<SdrObject::TakeContour(..)> has a value greater than 123000.

OD->AW: Can you please have a look.
Comment 7 Armin Le Grand 2009-06-22 15:09:26 UTC
AW: Added to CWS aw074, taking a look...
Comment 8 Armin Le Grand 2009-06-24 11:09:39 UTC
AW: Indeed, the contour has 123960 polygons in it's PolyPolygon. With thick
lines, this is a possible result. I will take a look how far thick lines were
taken into account in older versions...
Comment 9 Armin Le Grand 2009-06-24 11:13:06 UTC
AW: Old version painted to a Metafile and extracted polygon data from the
lines were not taken into account, so i will do the same in the new
implenetation and will set the LineWidth to hairline (0). Testing...
Comment 10 Armin Le Grand 2009-06-24 11:29:52 UTC
AW: With reduced line width to hairline, still 2452 polygons exist; i also have
to mention that the primitive creation of the 123960 polygons was done in second
range; just the user of that data may have had a problem. To check that (to be
safe) i need sw with debug. I will commit te first part of the fix...
Comment 11 Armin Le Grand 2009-06-24 13:23:15 UTC
AW: It's used in SwContourCache::ContourRect to create a TextRanger; not sure
what this is doing, but it seems not necessary for the loaded document. It could
be done on demand. Surely TextRanger and interacting with B2DPolyPolygons may be
also optimized.
Checked: TextRanger is in SVX and internally uses PolyPolygon (the old polygon).
Checking the conversion...
Ah, here is the problem. TextRanger::TextRanger converts the B2DPolyPolygon to a
PolyPolygon, inserting all sub-polygons. The possible sub-polygon count in the
old PolyPolygon is a USHORT, allowing 65535 sub-polygons. This is a potential
problem, writing a FUp-task (#i103068#).
For OOo 3.1.1, the problem is solved with the changes done.
Comment 12 Armin Le Grand 2009-07-06 16:40:17 UTC
AW: Ckecked with build, works as expected.
Comment 13 Armin Le Grand 2009-07-07 09:56:45 UTC
AW->WG: Please reviewas described
Comment 14 wolframgarten 2009-07-09 09:35:10 UTC
Verified in CWS.
Comment 15 wolframgarten 2009-07-30 11:35:55 UTC
Tested in m17. Closed.