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.
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!
(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.
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.
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 :)
@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?
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.
Looks similar or related to Bug 60418, Bug 61558
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
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.
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.
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.
Seems even worse now than before, freezing all the time. Strongly considering just coughing up for Word.
Created attachment 86857 [details] screenshot typical writer freeze on larger document.
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.
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.
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.
That's a great idea, I've done that, should I just attach the document here? It's rather large (17.6mb).
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!
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?
Perfect, thanks for all that detail
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.
(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.
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?
*** Bug 70842 has been marked as a duplicate of this bug. ***
(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.
(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?
The newest version I tried (4.1.3) was the most prone to locking up.
Changing Platform to ALL, as discussed in Bug 70842.
edited summary notes and added to 4.0 MAB list.
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.
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.
*** Bug 69201 has been marked as a duplicate of this bug. ***
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.
Mathias - are you running Linux by chance? If so, are you willing to try a bibisect?
I use Win7 64 bit and do not run Linux except on a VM. And I don't even know what a bibisect is.
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
*** Bug 73285 has been marked as a duplicate of this bug. ***
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?
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
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
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
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?
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.
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
@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.
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) :)
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
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.
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.
*** Bug 74435 has been marked as a duplicate of this bug. ***
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.
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.
Migrating Whiteboard tags to Keywords: (perf bibisected ) [NinjaEdit]