Bug 63433 - EDITING: Frequent freezes when scrolling large document with many pictures
Summary: EDITING: Frequent freezes when scrolling large document with many pictures
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.2.2 release
Hardware: All All
: medium major
Assignee: Not Assigned
URL:
Whiteboard: target:4.3.0 target:4.2.0 target:4.1.5
Keywords: bibisected, perf, regression
: 69201 70842 74435 (view as bug list)
Depends on:
Blocks: Image-Caching mab4.0
  Show dependency treegraph
 
Reported: 2013-04-11 15:38 UTC by Matthew Buxton
Modified: 2015-12-15 11:23 UTC (History)
14 users (show)

See Also:
Crash report or crash signature:


Attachments
screenshot (220.28 KB, image/jpeg)
2013-09-30 15:57 UTC, Matthew Buxton
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Buxton 2013-04-11 15:38:00 UTC
Working on a larger document (400+ pages) stored locally on a Windows 8 laptop (Core i7, GTX640M, SSD drive) causes frequent freezing. Scrolling down a document can suddenly cause Writer to freeze completely, even the window cannot be minimized. Sometimes it takes several minutes before the software is usable again.
Comment 1 Joel Madero 2013-04-11 16:21:53 UTC
We'll need the document to verify. Not sure about the size,  if it's much too large email is an option or dropbox/google drive, etc....

When you look at computer use, are you seeing spikes in Memory use or CPU use? Also, was this a problem with 3.6 series? Is the document a .doc or native format? If it's a .doc, have you tested saving it as native format and seen same results?

Marking as NEEDINFO, once you provide document and answer those couple question, mark as UNCONFIRMED and we will look into it. Thanks!
Comment 2 Matthew Buxton 2013-04-11 17:33:13 UTC
(In reply to comment #1)
> We'll need the document to verify. Not sure about the size,  if it's much
> too large email is an option or dropbox/google drive, etc....
> 
> When you look at computer use, are you seeing spikes in Memory use or CPU
> use? Also, was this a problem with 3.6 series? Is the document a .doc or
> native format? If it's a .doc, have you tested saving it as native format
> and seen same results?
> 
> Marking as NEEDINFO, once you provide document and answer those couple
> question, mark as UNCONFIRMED and we will look into it. Thanks!

I can't really send the document, it's a book I've written, the only one that's actually selling at the moment. If the .odt file leaked out it could be devastating. It's 435 pages with a big index at the end and many pictures.

According to Task Manager, CPU activity spikes to around 18% to 20% for Writer during the freeze. Memory usage seems to stay the same.

Document is in native format.

I never ran 3.6 series on this laptop, wasn't a problem on my desktop. My desktop's out of action at the moment but I will test on there when it's repaired.
Comment 3 Joel Madero 2013-04-12 02:47:45 UTC
understood, just do as much testing as you can. The spike is concerning, does it happen if you just open the file and let it sit there doing nothing?

Also, if you can uninstall 4 and install 3.6 as a test, that would help tremendously to check to see if it's a regression.
Comment 4 Joel Madero 2013-04-12 02:52:23 UTC
adding a "see also" -- might be related (different components so possibly not, but both experiencing high CPU usage, slow, Windows based (although one is 7 the other is 8). Apologies if these are not related :)
Comment 5 Joel Madero 2013-04-12 02:53:19 UTC
@Michael - can you offer any other guidance of how we can pinpoint this one, is quite serious but without a test document, is there anything else we can request?
Comment 6 Matthew Buxton 2013-04-18 10:03:50 UTC
Can confirm it doesn't seem to CPU usage spike if the document is just sat there open, only when scrolling through. I am switching back to OpenOffice on a desktop PC while I get this finished then I'll investigate further.
Comment 7 ign_christian 2013-07-09 14:40:38 UTC
Looks similar or related to Bug 60418, Bug 61558
Comment 8 Stefan_Lange_KA@T-Online.de 2013-09-07 19:30:05 UTC
I have an other system (Windows 7 Home Premium 64 bit, Pentium (R) Dual-Core T4500 2,3 Ghz, memory 4,00 GHz), but I have the same problem, that LibreOffice Writer (4.0.4 and 4.1.1) often freezes when I am working with a large document. 
I have a document of 317 pages, that I could give you to reproduce the behavior of the programm. Unfortunately it is very big (because of many pictures more than 40 MB), so I can't attach it to this message. On what way can I send the document?
Yours sincerly
Stefan Lange
Comment 9 Stefan_Lange_KA@T-Online.de 2013-09-27 19:10:40 UTC
Is this bug currently edited by someone? To edit my large document, I can not use respectively use only limited the Versions 4.0 and 4.1.  Currently the last usable LibreOffice version is 3.6.7.
Comment 10 Joel Madero 2013-09-27 20:14:39 UTC
ah, so this is undoubtedly down to the mess of code we have dealing with images. In which case this is a duplicate but I'd have to track down the dupe, lots of people though know that our image code is a wreck but that it's really really hard (weeks of expert developers) time to fix. It needs completely reworked from my understanding.
Comment 11 Matthew Buxton 2013-09-28 09:05:45 UTC
I've another book I need to finish before Christmas so I'll be giving this another good testing, this time on a quad core desktop.
Comment 12 Matthew Buxton 2013-09-30 14:47:03 UTC
Seems even worse now than before, freezing all the time. Strongly considering just coughing up for Word.
Comment 13 Matthew Buxton 2013-09-30 15:57:23 UTC
Created attachment 86857 [details]
screenshot

typical writer freeze on larger document.
Comment 14 Matthew Buxton 2013-09-30 15:58:47 UTC
Problem seems worse when scrolling up (i.e to a previous page). Sometimes window minimizes itself too and causes problems with other open windows on the monitor.
Comment 15 Joel Madero 2013-09-30 16:36:23 UTC
I am going to have to close this as INVALID without an attachment showing the problem. Letting this one stay open to just have a bunch of people saying "me too!" but not have any way for us to test the bug or debug the issue means not much we can do. Apologies.

If someone can post a document showing this problem, set as UNCONFIRMED and we'll go from there.

As for the other issue (minimizing and what not) please keep this bug to one issue, if there is a separate issue, open another bug as more than one issue just clutters comments and makes it hard to follow the bug. I doubt that one is a bug with LibreOffice as minimizing is controlled by the OS, not by our product - but if you can provide clear and concise reproducible steps for that on a new bug, we'll see if we can confirm it.
Comment 16 Joel Madero 2013-09-30 16:39:33 UTC
One possible suggestion - save a copy of your file, and do a replace for like 15 of the letters with other characters - this way the document itself will be unreadable but we'll see the problem.
Comment 17 Matthew Buxton 2013-09-30 17:30:20 UTC
That's a great idea, I've done that, should I just attach the document here? It's rather large (17.6mb).
Comment 18 Joel Madero 2013-09-30 18:07:28 UTC
it's actually too large to attach to FDO - can you put it on google docs, drop box or some such place where you can share a link?

Moving back to UNCONFIRMED with the assumption that a link will be provided in the next couple weeks :) Thanks!
Comment 19 Matthew Buxton 2013-09-30 18:15:30 UTC
Here's a dropbox link https://dl.dropboxusercontent.com/u/1488717/Windows%208.1%20superguide-obscured.odt

Some other notes on this machine:-

OS Name	Microsoft Windows 8 Pro
Version	6.2.9200 Build 9200
Other OS Description 	Not Available
OS Manufacturer	Microsoft Corporation
System Name	W8-GAMES
System Manufacturer	Gigabyte Technology Co., Ltd.
System Model	X58A-UD5
System Type	x64-based PC
System SKU	
Processor	Intel(R) Core(TM) i7 CPU         950  @ 3.07GHz, 3059 Mhz, 4 Core(s), 8 Logical Processor(s)
BIOS Version/Date	Award Software International, Inc. FD, 01/02/2011
Installed Physical Memory (RAM)	12.0 GB
Total Physical Memory	12.0 GB
Available Physical Memory	5.94 GB
Total Virtual Memory	13.7 GB
Available Virtual Memory	6.82 GB
Page File Space	1.69 GB
Page File	C:\pagefile.sys

Graphics:- NVIDIA GeForce GTX 770

Windows 8 installation is less than a month old (had to reinstall it recently thanks to a screwy driver).

No problems browsing the document in Word 2013 and no problems (or at least nothing anywhere near as serious) so far in OpenOffice 4. Weird huh?
Comment 20 Joel Madero 2013-09-30 18:19:59 UTC
Perfect, thanks for all that detail
Comment 21 Gene 2013-10-24 20:08:27 UTC
Here's another document that will cause this issue:
http://www.geneb.org/rostock-max/Rostock-MAX-Assembly-Guide.odt

I filed this with bug #70842.
Comment 22 Cor Nouws 2013-10-24 20:52:18 UTC
(In reply to comment #12)
> Seems even worse now than before, freezing all the time. 

Tip: in general using key board (PageUp/Down) and Navigator works fine or at least much better.
Comment 23 tommy27 2013-11-24 18:11:50 UTC
reproduced with LibO 4.1.3.2 under Win7 64bit

I experience freezes when doing "mad scrolling" with the test document either using the scrollbar or the page-up/page-down keys.

@Matthew Buxton
is the freeze frequency different with recent 4.1.3.2 and the old 4.0.2.2 version that you used when you first reported the bug?
Comment 24 tommy27 2013-11-24 18:24:07 UTC
*** Bug 70842 has been marked as a duplicate of this bug. ***
Comment 25 Matthew Buxton 2013-11-24 18:34:29 UTC
(In reply to comment #23)
> reproduced with LibO 4.1.3.2 under Win7 64bit
> 
> I experience freezes when doing "mad scrolling" with the test document
> either using the scrollbar or the page-up/page-down keys.
> 
> @Matthew Buxton
> is the freeze frequency different with recent 4.1.3.2 and the old 4.0.2.2
> version that you used when you first reported the bug?

Yes it certainly seemed more frequent. I switched back to OpenOffice to finish the book and did not experience any freezing.
Comment 26 tommy27 2013-11-24 18:43:31 UTC
(In reply to comment #25)
> > @Matthew Buxton
> > is the freeze frequency different with recent 4.1.3.2 and the old 4.0.2.2
> > version that you used when you first reported the bug?
> 
> Yes it certainly seemed more frequent. I switched back to OpenOffice to
> finish the book and did not experience any freezing.

please, make a clear statement about which version had a worst freeze frequency: 4.0.2 or 4.1.3?
Comment 27 Matthew Buxton 2013-11-24 23:39:16 UTC
The newest version I tried (4.1.3) was the most prone to locking up.
Comment 28 Kevin Suo 2013-11-25 01:42:51 UTC
Changing Platform to ALL, as discussed in Bug 70842.
Comment 29 tommy27 2013-11-25 02:43:00 UTC
edited summary notes and added to 4.0 MAB list.
Comment 30 tommy27 2013-11-25 02:53:09 UTC
as already pointed in Comment 9 the issue doesn't affect LibO 3.6.7 (no freeze even with "crazy scrolling") hence it's a regression of the 4.0.x branch.
Comment 31 Ron House 2013-11-26 04:02:33 UTC
Ditto as #30 tommy27. Scrolling freezes with large doc and lots of images. Using Debian Wheezy - all LO 4.x versions tried are the same.

Some success reducing the problem by (1) turning off transparency for selections, (2) turning off java. But trouble is not fixed. Delays still 10-15 seconds per one or two page scrolls.

This is a really serious issue. The product is unusable as-is. Thanks to all trying to help out with a fix.
Comment 32 Matthias Basler 2014-01-03 21:58:45 UTC
*** Bug 69201 has been marked as a duplicate of this bug. ***
Comment 33 Matthias Basler 2014-01-03 22:09:33 UTC
Just in case it helps: As noted in issue 69201 (duplicate) and 67582 (duplicate?), affected documents also initially load much slower in LO 4.1.x than in 3.6.x where the problem does not occur. Might have the same root cause as the freezing.
Comment 34 Joel Madero 2014-01-04 06:53:39 UTC
Mathias - are you running Linux by chance? If so, are you willing to try a bibisect?
Comment 35 Matthias Basler 2014-01-04 09:04:43 UTC
I use Win7 64 bit and do not run Linux except on a VM. And I don't even know what a bibisect is.
Comment 36 Joel Madero 2014-01-04 19:34:27 UTC
It isn't that difficult to do and it helps a ton. https://wiki.documentfoundation.org/QA/HowToBibisect

You can do it within a VM no problem - it will help us narrow at what point (what range of commits) actually broke this

If you do attempt it, likely you'll want the bibisect40 package
Comment 37 tommy27 2014-01-04 23:03:18 UTC
*** Bug 73285 has been marked as a duplicate of this bug. ***
Comment 38 Matthias Basler 2014-01-05 11:52:00 UTC
BibiSect: > It isn't that difficult to do
Difficult is relative: Had to watch the tutorial video, setup a new VM, download 4GB and another 3.6 GB (several hours), wait minutes to unpack, discover that VM HDD is to small, format and mount another one by command line (I hate command lines...), unpack again, wonder where the "./opt/program/soffice" is, find out it comes during checkout and then finally was able to do the bibisect, which turned out problematic because some builds failed to load the document in question, which made the process rather lenghty.

Now, about 8 hrs later I finally finished. Here are the results:

bibisect40:
- Generally good on 3.6 builds in bibisect 40

One of the last good builds (Well, it had a header ledger line display problem, but this was another issue) :
[09b9b2bf979295d83b5a96c42dc2e4dbdc11e8a2] source-hash-13cb9d9d1ac672d6ef22cee98237b0285e03cda3

One of the first bad builds :
[99fb4d5c4493406d720bb58eedd6c79b2c304c77] source-hash-982b7cb498c3ea1106c5d2184f84989d99b1d942

About 33 builds of versions of 3.7.0.0.alpha0+ inbetween fail to load the test document:
	terminate called after throwing an instance of 'std::length_error'
	  what():  vector::reserve

One more note: LO 4.2.0.1 pre-release does not have this issue for me (on Windows). It behaves normal, in contrast to 4.1.4.2. So maybe this issue has been fixed on trunk already?
Comment 39 Joel Madero 2014-01-05 18:19:34 UTC
Thanks for dedicating 8 hours to it ;) I suppose you're right - after a few goes at it, usually takes 15 minutes or so.

That being said, if you don't see the problem in 4.2 then yes, seems like something fixed it already - let's get confirmation from another person who is affected and then close as WFM
Comment 40 tommy27 2014-01-05 19:55:59 UTC
works fine indeed on 4.2.0.1rc

mad scrolling causes no freeze unlike previous 4.0.x and 4.1.x releases.

set status RESOLVED WORKSFORME
Comment 41 tommy27 2014-01-05 19:56:49 UTC
works fine also in Version: 4.2.0.0.beta2+
Build ID: 039dadf3b48484ba5d1fc71de5561288e6b7c5cb
TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2013-12-06_22:54:58
Comment 42 Matthias Basler 2014-01-05 22:23:46 UTC
Sorry if I am ignorant of the procedures here, but shouldn't be checked first if the correction has been packported to the 4.1 and 4.0 branch before closing this as "WORKSFORME".

Reasoning is: Older versions are supposed to become the stable branches ("for corporate deployments" later when 4.2 is out, and in my understanding this means that they are supposed to get all relevant bug fixes of trunk backported or that explicit bug fixes are created for them if necessary.
Am I wrong?
Comment 43 Gene 2014-01-05 23:01:43 UTC
FYI, I just tested my document problem with 4.2.0.1 from the libreoffice.org site (pre-release download link) and it appears the issue has been resolved.  Thank you!

g.
Comment 44 Joel Madero 2014-01-06 00:10:54 UTC
With regards to WFM -

We tend to not backport a lot because it takes a lot of time to track down what patch/es fixed the problem and backporting requires A LOT more testing to ensure there aren't any regressions. In this case, I suspect it was part of a large commit and therefore, tracking it down and backporting is unlikely. It's fixed in 4.2, 4.0 is already end of life (https://wiki.documentfoundation.org/ReleasePlan#4.0_release) and with our incredibly fast release pace, 4.1 will be end of life in May, spending a ton of time tracking down the commits and testing them into oblivion just isn't efficient use of our time
Comment 45 tommy27 2014-01-06 03:36:26 UTC
@Joel

maybe an early 4.2.x bibisect try could be worth it, just to undestand which committ effectively fixed the regression introduced in the 4.0.x branch.

as said before, the bug was not present in 3.6.x, appeared in 4.0.x and persists in 4.1.x and has been fixed again in 4.2.x

even if they do not wanna backport the fix from 4.2.x to 4.1.x, I think it would be useful for the devs to know what caused this "work-regression-work" change to avoid doing it again in the future.
Comment 46 Joel Madero 2014-01-06 03:54:05 UTC
Sure - that wouldn't hurt if someone volunteers to do it ;) Since I haven't even reproduced the issue, I wouldn't be of much use here. If someone wants to use the recent bibisect package to try to narrow down where the fix came from, paste the entire log here and output, perhaps we can do something with it. A few in QA are quite good at finding the potential fix (Joren for instance is brilliant at this) :)
Comment 47 Joel Madero 2014-01-06 04:33:27 UTC
So I just tried and it's pretty confusing doing a reverse bibisect and I was unsuccessful in pinning down the range. If someone else wants to attempt - remember that it's a reverse bibisect, so if you do "git bisect bad" it goes to an OLDER version - which isn't what we want, you want to move forward. So I tried tricking it by saying git bisect good (when it was bad), but failed to get a decent range. It seems like there may have been slow incremental improvements over some range of commits. 

If someone else succeeds, awesome :) I can't put any more time towards it since it's indeed fixed in 4.2
Comment 48 tommy27 2014-01-11 17:21:01 UTC
*** Bug 73285 has been marked as a duplicate of this bug. ***
Comment 49 Michael Stahl (CIB) 2014-02-03 12:39:05 UTC
so 2e5167528f7566dd9b000e50fc1610b7bf99132a fixed it - but it's rather scary for 4.1 at this point, that commit changes to a different mechanism for rendering Writer images and has introduced 2 known regression by itself, and i can't tell what else it may break or what other commits in 4.2 it may depend upon.

best to leave this fix for 4.2 i guess.
Comment 50 Michael Stahl (CIB) 2014-02-03 12:59:47 UTC
now it turns out that this is actually introduced with this commit:

commit 8af09bf33291df2fb2bfbbd6e42f9bf074fcc4fc
Author:     Cédric Bosdonnat <cedric.bosdonnat.ooo@free.fr>
AuthorDate: Mon Sep 3 16:52:47 2012 +0200

    n#777699: Clip the objects to the pagewe are painting

... which i just fixed as bug 74435 :-/

the fact that the commit in comment #49 also helps here is surprising.
Comment 51 Michael Stahl (CIB) 2014-02-03 13:01:04 UTC
*** Bug 74435 has been marked as a duplicate of this bug. ***
Comment 52 Commit Notification 2014-02-04 12:18:23 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=5200d19a541b59141d15e3780f5197569b6b135e&h=libreoffice-4-1

fdo#63433 fdo#74435: SdrPageView::DrawLayer(): avoid spuriously visible images


It will be available in LibreOffice 4.1.6.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 53 Commit Notification 2014-02-05 11:39:04 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-4-1-5":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=94ae67fb31360343241010598d517b8c378bcf82&h=libreoffice-4-1-5

fdo#63433 fdo#74435: SdrPageView::DrawLayer(): avoid spuriously visible images


It will be available already in LibreOffice 4.1.5.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 54 Robinson Tryon (qubit) 2015-12-15 11:23:26 UTC
Migrating Whiteboard tags to Keywords: (perf bibisected )
[NinjaEdit]