My document is 158k wds, with a few hundred comments; 569 pages. The window opened and it was too wide, so I dragged it to narrow the window by about 25% to makie it a bit less wide. LO then started using all CPU time, and it all froze, and I watched as the content of the window frame was redrawn, with a 1 pixel shift left, with about 20-30 seconds spent between each shift, as if it were redrawing the entire 569 pages, not just what was on display. It took about 15-20 mins to finish the redraw before I could continue work. This is on Ubuntu 16.04 LTS, using Metacity (Flashback) for the desktop, on an Intel 64bit CPU with 16GB RAM. This had been happening a month or so ago with an earlier version of LO and a different version of Metacity (that tended to crash). I'm now using an rc version of Metacity that fixes metcaity's crash bug. That version does seem to suffer from other problems, however (5% of the time, dialog windows open with no contents drawn, or, more rarely, partially drawn). I mention that only in case it might affect LO's performance when re-sizing. rc libmetacity-private0a 1:2.34.13-0ubuntu4.1 amd64 library for the Metacity window manager ii libmetacity-private3a:amd64 1:3.18.4-0ubuntu0.1 amd64 library for the Metacity window manager ii metacity 1:3.18.4-0ubuntu0.1 amd64 lightweight GTK+ window manager ii metacity-common 1:3.18.4-0ubuntu0.1 all shared files for the Metacity window manager
Same as bug 99153?
Hmm. It could be. Though I'm not using Unity, I'm using Metacity (and one of the "traditional" UI options like Flashback for the desktop). And that freport said it was only applicable to Unity. Also, I just tried a little experiment: 1. Resized a short 6-page document. Instant resizing. 2. Resized a version of half my MS (280pp and thousands of editor comments) 2 seconds to resize. 3. Resized my MS with just my comments (569pp and hundreds of comments) 30-seconds to resize. Note that this was after exiting LO some hours earlier and re-opening the files I had open when I first reported this. 30 seconds to resize is not great, but it's quite liveable with. 15-20 mins is not so much. Yet this was the same file that earlier had taken around 20 mins. I observed the CPU went very busy, but I brought the browser to the foreground over the top, assuming it would take a similar length of time: it didn't. Though I just now brought up doc #2 in the above list to the foreground, and accidentally maximised it vertically and found I couldn't un-maximise it via the rectangle icon of the window, nor could I dock it with the "-" icon. I had to Alt-mouse move it partly off screen, re-size, and then it behaved normally: though the vertical re-sizing showed similar behaviour: window went dark grey as it went to 100% CPU, and I got to see tiny vertical incremental redraws as the window contents were slowly redrawn over and over to fill the space. But again, that only took about 20 seconds. I just finished resizing doc #3 again, this time not obscured, but again, it finished its incremental redraws after about 20 seconds; with each redraw taking about 1 second, not 20-30 seconds. I don't know what to make of the weird variability in the behaviour I'm seeing. And it certainly seems similar to bug 99153, but again, doesn't seem to entirely match. What do you think?
Yeah, I guess it doesn't match. This is a way to get data on performance problems, but it runs VERY slowly: https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_callgrind_trace Note that you would also need: "The debugging package for (older) Debian, Ubuntu or their derivatives is libreoffice-dbg"
What about if I attached to it with gdb and just got a stack backtrace - would that be much help?
(In reply to Luke Kendall from comment #4) > What about if I attached to it with gdb and just got a stack backtrace - > would that be much help? Well, maybe you could do the callgrind and cancel out of it after you get bored.
I guess the problem is with the gtk2 backend only. Please, could you do the same as in https://bugs.documentfoundation.org/show_bug.cgi?id=103698#c1 ? Best regards. JBF
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping-20170531
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-20170628