Issue 121462 - Moving pictures causes infinite compute loop
Summary: Moving pictures causes infinite compute loop
Alias: None
Product: Writer
Classification: Application
Component: formatting (show other issues)
Version: 3.4.1
Hardware: All All
: P3 Major (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact: miele angelo
Depends on:
Blocks: 121500
  Show dependency tree
Reported: 2012-12-11 07:20 UTC by openoffice
Modified: 2017-05-20 10:12 UTC (History)
4 users (show)

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

test file with many attachments included by link, not embedded (834.48 KB, application/vnd.oasis.opendocument.text)
2013-02-19 16:26 UTC, openoffice
no flags Details
cut down version of writer file with fewer image references (831.52 KB, application/vnd.oasis.opendocument.text)
2013-02-19 21:57 UTC, openoffice
no flags Details
Fewer images still (600.98 KB, application/vnd.oasis.opendocument.text)
2013-02-20 03:35 UTC, openoffice
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description openoffice 2012-12-11 07:20:44 UTC
Unfortunately, I am not sure how to reliably reproduce this.
I have a 2 page document with about 15 photos per page,
scattered around with text running around them.
The photos are anchored to paragraphs and a few at the bottom of page 1
and the top of page 2 are anchored to the page itself.

Clicking to select one of the images or clicking to pop up the menu on one of the images sometimes causes all or most of the visible images to disappear, with only their frames showing, and the cpu goes into some kind of infinite loop.

You can see this on a FreeBSD system by running "top -n 5" in an xterm and then working with the document.  Normally the cpu is down around 0-10%; when the problem occurs it shoots up above 100% and stays up there forever (4 cpu system).

Interestingly, scrolling the page up and down will usually cause the images to repaint immediately, and the cpu usage gradually lowers itself down to where it is normally.

If I can figure out a repeatable case I will post it.
Comment 1 openoffice 2012-12-11 07:59:41 UTC
The heavy compute loop also happens sometimes simply by hiding and uncovering the page.  I thought it might just be slow recomputing the text layout / geometry, but the cpu stays busy forever.
Comment 2 Oliver-Rainer Wittmann 2012-12-11 09:09:03 UTC
CC myself
Comment 3 binguo 2012-12-21 07:56:39 UTC
would you please provide sample file which can repro this bug? thank you.
Comment 4 openoffice 2012-12-23 19:59:14 UTC
Working on a way to reproduce it; having trouble because other weird things 
are happening.  The document as written contains links to pictures; replacing
them with frames seems to make the problem go away, or at least I can't get it
to reproduce that way.  The images in the original document were links, so in
order to make a test case I'm trying to embed them in the doc.

The document is a holiday letter; I've been printing it off a few at a time.
Sometimes when the small "Printing..." notice dismisses itself, the images
which were previously covered up by the main print dialog never redraw as
images, and the printed page simply prints the outlines as well.  Not sure
what that is indicative of -- I was totally surprised, as I assumed it was
only a screen redraw issue.

This is all pretty useless, I know, but will try to get a test case.
Comment 5 miele angelo 2013-01-17 18:46:40 UTC
I need a sample file to try this bug. Thanks
Comment 6 openoffice 2013-02-19 16:26:46 UTC
Created attachment 80301 [details]
test file with many attachments included by link, not embedded

I have tried unsuccessfully to cut this file down in size and include the images directly.  I wasn't able to do it one image at a time due to lack of time; I'm fairly certain a much smaller file with many fewer images will cause the error.  I don't know if this will fail if the images themselves are not present.
When it originally failed, only the images and text on the first two pages were present.

I will continue to try to produce a smaller test case.

Load the file into writer, click once in the scroll bar so you're positioned viewing the bottom of page 1 and the top of page 2, then forget about it.  Run a "top 5" job as you do your regular work.  At some point, exposing the writer window and needing a repaint will cause openoffice to become the top cpu consuming job, and the images will not repaint -- oo will sit there chewing up cpu.  Since the images are not there in this file, I don't know what will happen.
Comment 7 openoffice 2013-02-19 21:57:01 UTC
Created attachment 80302 [details]
cut down version of writer file with fewer image references

Use TestCPUSpin_3_fails_20130219_1.odt instead of the previously uploaded file.
Comment 8 openoffice 2013-02-20 03:35:22 UTC
Created attachment 80306 [details]
Fewer images still

As supplied, when initially loaded into writer the cursor is positioned after the period at the very end of the text, and the document is scrolled so that approximately the top half of the images on page 2 are visible.  All of the text is on page one.  
When initially loaded into writer, about half of the images don't paint -- none on the 3 on page 2, and the 3 on the right at the bottom part of page 1 (the only 3 on the right on page 1 which are visible in my layout).  The images on the left paint.  The cursor will be blinking rapidly, and the "top 5" will show increasing cpu consumption -- mine goes up over 100% (4 processor box).
If you type a single character, the frantic cursor blinking will quit, the images will paint, and things return to normal.
Hope this helps and it's reproducible for whoever is working on it.
Comment 9 Edwin Sharp 2014-03-31 11:35:23 UTC
No problem with attachment 80306 [details]
AOO410m14(Build:9760)  -  Rev. 1582709
2014-03-30_04:11:07 - Rev. 1583103