Created attachment 119863 [details] Four screenshots of LO behaviour when the problem strikes Since installing 5.0.2.2, the menus randomly stop working altogether. The current occasion happened when I selected several paragraphs of text to change the font and font size. I was able to change the font, but although the text stayed selected, clicking on the font size drop-down had no effect. Nor did typing the point size directly into the text field - it was ignored. Keyboard shortcuts still work. All open LO documents suffer the same problem: the drop-downs stop working in all of them. Each window looks basically normal, except with some refresh problems. E.g. in one, when I click away and back to it, the entire canvas area for the window is a pale gray, with a flashing cursor and nothing else, at the last cursor insertion point. If I click elsewhere to move the insertion point, the document and all the UI elements are instantly re-drawn. At other times, if I click away (bringing other windows on top of the LO window), when I click back on the LO window titlebar, the canvas area does not refresh (apart from the window title bar and frame drawn by X11), again until I click into the window. But this isn't always true: while entering this bug report, I did something different (see below), and now when I click back into the document window nothing at all happens (not even the balloon text when hovering over UI controls). But coming back to this bug report and then clicking back in *did* make the window redraw correctly. Also, the balloon text when hovering over UI controls is working again. What I had done was check to see if the UI controls that weren't drop-down menus still worked: I clicked on the Bullet-text button, and it did indeed work. But when I used Ctrl-Z to undo that change, it did not visibly change. I did several more Undo operations, and gradually realised it was undoing, but only showing me the undo selection area without actually redrawing the text displayed. So I used Redo to re-do all the changes, then one last Undo to try to Undo the Bullet-text change: after that, the failure to redraw occurred. I see however that when I hover to make the balloon text appear, it does not erase, so as you hove over more controls, you get a smear of various texts appearing. It seems that clicking around in the window "enough", eventually makes the window redraw. I'll attach some screenshots. Note that while the keyboard shortcuts work, the panels that are brought up are not rendered - e.g. the Save dialogue is empty, and you have to guess/remember which option is highlighted, and what will happen when you hit Enter. I have not been able to reliably reproduce this, but it has happened about six times in the day since I installed 5.0.2.2. I note that something like this has been described for many years (e.g. 59984, 63936), but been marked Resolved as it could not be reproduced. I can confirm that quitting from LO and restarting it "solves" the problem.
did you try resetting the user profile? https://wiki.documentfoundation.org/UserProfile
No, I hadn't tried that. I've done so now, and I'll post an update if the problem recurs, or if a day has passed and the problem fails to recur.
Created attachment 119865 [details] gdb stack backtrace This is the gdb session from LO endlessly (?) scrolling. I tried for a minute or two to stop it via the mouse, by hitting Esc, but nothing worked. I alt-tabbed to a Terminal and ran gdb as root, and attached to the process and then after the backtrace, killed it.
Well, I don't know if this is related or not: let me know if I should submit it as a separate bug... I opened up two files - both large, about 120,000 words long. One is my novel, which LO edits in quite a snappy fashion (let's call this MS). The other is basically the same, but with a very large number of comments from a professional editor (let's call this MS-ed): LO clearly has some kind of O(N^2) algorithm when it comes to handling comments, since it struggles horribly to edit this file. (Both are in .odt format.) Anyway, that's just context background. I opened MS, no problem, and MS-ed. I clicked in the scroll region below the scroll-thumb in MS-ed to jump down a page (since scrolling using the mouse wheel is very laggy - it can take a minute for LO to finish its painfully slow and staggering scrolling). What happened was that LO never stopped scrolling. "top" shows it was using over 99% CPU. I couldn't get X11 to let me change window focus - I had to use Alt-tab to get to a Terminal. Nor did the mouse scroll wheel work while LO was madly scrolling. In the end I attached to the process in gdb, got a backtrace, and killed the LO process. As soon as I did so, X11 mouse events started working correctly again. I restarted LO, and almost the same thing happened: one mouse click in the scroll region, and LO scrolled page by page by page by page... I tried to drag the scroll thumb back up to stop it, then releaed the mouse. No mouse events were accepted elsewhere (e.g. I couldn't change focus using the mouse), but after about a minute the scrolling stopped and the system started responding to mouse events normally. I don't dare use the mouse to scroll, though. I can use Page-up/down safely (each page-scroll takes about 5 secs to complete). This is on an Intel NUC (AMD x64) with 16GB RAM. With LO running but not doing any editing: top - 16:17:43 up 91 days, 19:53, 14 users, load average: 0.50, 0.75, 0.82 Tasks: 267 total, 3 running, 263 sleeping, 0 stopped, 1 zombie %Cpu(s): 12.8 us, 0.6 sy, 0.0 ni, 86.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 16101596 total, 13980472 used, 2121124 free, 2462616 buffers KiB Swap: 9820156 total, 1089084 used, 8731072 free. 4949980 cached Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 29840 luke 20 0 3548172 1.821g 47576 S 48.8 11.9 1066:09 firefox 3221 luke 20 0 687556 25736 5800 S 2.3 0.2 30:54.65 gnome-term+ 1762 root 20 0 733288 337232 203572 S 1.3 2.1 2097:51 Xorg 2977 luke 20 0 410924 4128 2484 S 1.0 0.0 1471:33 indicator-+ ...
(In reply to Luke Kendall from comment #3) > Created attachment 119865 [details] > gdb stack backtrace > > This is the gdb session from LO endlessly (?) scrolling. I tried for a > minute or two to stop it via the mouse, by hitting Esc, but nothing worked. > I alt-tabbed to a Terminal and ran gdb as root, and attached to the process > and then after the backtrace, killed it. Oh - you'll no doubt notice the remarkably large number in the call to malloc.
Just a note re the slow performance when there are many comments - I've submitted a separate bug for that (95244).
I am right now experiencing a similar problem. I had just clicked into the body of a comment, and went to choose the Format al comments option, and LO locked up almost completely. I noticed that the main Format menu had dropped down - I'm not sure why. (Earlier in the day, before I split the many-comments file in two, I had yet another bizarre behaviour: when clicking on the small "down arrow" in the little scrollbar within a comment, instead of the comment scrolling, the text cursor insertion point in the main document moved down one line each time I clicked on the down-scroll button in the comment scrollbar!) Anyway, LO is once again using over 99% CPU: top - 22:56:54 up 92 days, 2:32, 15 users, load average: 1.74, 1.69, 1.51 Tasks: 267 total, 3 running, 263 sleeping, 0 stopped, 1 zombie %Cpu(s): 37.6 us, 0.4 sy, 0.0 ni, 62.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 16101596 total, 14675220 used, 1426376 free, 2485200 buffers KiB Swap: 9820156 total, 1087620 used, 8732536 free. 4834772 cached Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 612 luke 20 0 2361204 829372 79872 R 100.0 5.2 40:06.64 soffice.bin 29840 luke 20 0 3746448 2.033g 47356 S 43.5 13.2 1167:08 firefox ... In fact, at first I could do nothing whatsoever in my X1 session - even Alt-Tab wouldn't let me change focus. I did Ctrl-Alt-F1 to get a text console and ran gdb to get a stack traceback, and when I went back to the X session via Ctrl-Alt-F7 I could at least change focus again, and mouse events could get through to everything in a normal way. One unusual thing that may be related: it's pretty likely that a "Rest break" window popped up while I was in the middle of using LO. Could it be that LO is vulnerable to having the focus stolen from it unexpectedly? I have the Workrave software installed to remind me to take breaks. It's quite possible that a brief "30 second break" window had popped up to take focus during each of the earlier incidents. I know that the longer "Rest break" panel had only been on screen for 15 seconds when the latest problem occurred. I'm so accustomed to them that I may not have even noticed it, if that was correlated to the LO problems. The stack backtrace from gdb is different and much shorter this time: 0x00007f79c08cf5eb in XCheckIfEvent () from /usr/lib/x86_64-linux-gnu/libX11.so.6 (gdb) where #0 0x00007f79c08cf5eb in XCheckIfEvent () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #1 0x00007f79b0834e1f in X11SalInstance::AnyInput(VclInputFlags) () from /opt/libreoffice5.0/program/libvclplug_genlo.so #2 0x00007f798a631192 in SwLayIdle::_DoIdleJob(SwContentFrm const*, SwLayIdle::IdleJobType) () from /opt/libreoffice5.0/program/../program/libswlo.so #3 0x00007f798a6313dd in SwLayIdle::DoIdleJob(SwLayIdle::IdleJobType, bool) () from /opt/libreoffice5.0/program/../program/libswlo.so #4 0x00007f798a6343c0 in SwLayIdle::SwLayIdle(SwRootFrm*, SwViewShellImp*) () from /opt/libreoffice5.0/program/../program/libswlo.so #5 0x00007f798a964a57 in SwViewShell::LayoutIdle() () from /opt/libreoffice5.0/program/../program/libswlo.so #6 0x00007f798a48f176 in sw::DocumentTimerManager::DoIdleJobs(Idle*) () from /opt/libreoffice5.0/program/../program/libswlo.so #7 0x00007f79c4df50bf in ImplSchedulerData::Invoke() () from /opt/libreoffice5.0/program/libmergedlo.so #8 0x00007f79c4df522f in Scheduler::ProcessTaskScheduling(bool) () from /opt/libreoffice5.0/program/libmergedlo.so #9 0x00007f79c4e02400 in Application::Yield() () from /opt/libreoffice5.0/program/libmergedlo.so #10 0x00007f79c4e024b5 in Application::Execute() () from /opt/libreoffice5.0/program/libmergedlo.so #11 0x00007f79c3f14a33 in desktop::Desktop::Main() () from /opt/libreoffice5.0/program/libmergedlo.so #12 0x00007f79c4e07729 in ImplSVMain() () from /opt/libreoffice5.0/program/libmergedlo.so #13 0x00007f79c4e07772 in SVMain() () from /opt/libreoffice5.0/program/libmergedlo.so #14 0x00007f79c3f338a2 in soffice_main () from /opt/libreoffice5.0/program/libmergedlo.so #15 0x000000000040075b in main () Now, I said LO was almost completely locked up. Although I could not get the screen to refresh, or any UI element to respond, at one point when I clicked into the window, one small paragraph of text (about 3 lines long) did get redrawn in the LO canvas, along with the cursor (which was in that paragraph). No other UI element would operate, Ctrl-S would not save the document, and nor could I close it by clicking on the Close icon. I "rolled up" both windows ("MS" and "MS-ed" - part 1) to add this comment. Just now I "unrolled" the MS window and tried another Ctrl-S, and this time I saw the "Saving" message and "save progress bar draw. Also, LO redrew just the Comment identifiers. I'll take a new screenshot (LO-5.0-lockup-PM.png). Unfortunately, from looking in the directory, I can see that LO has not completed saving the file - the newest version is from over an hour ago. Because I *really* don't want to lose the creative work I've done, which I may not be able to reproduce, and because LO seems to respond somewhat, I'll leave it running at 100% CPU in the hope that sometime overnight it completes the Save.
Created attachment 119879 [details] Another screenshot - LO-5.0-lockup-PM.png "Dave Taylor" is the professional editor. I didn't think to fill in my details again after moving the configuration aside, so I'm "unknown author" in the screenshot.
Yippee! 30 mins later, the LO window popped up a panel (from me hitting the Close icon) asking if I wanted to save my changes. Neither the Save panel nor the main window was redrawn, but I knew what it was asking, so hit Enter, and 30 secs later the Save progress bar appeared and seemed to run to completion, and indeed, the document is now updated in my directory. Whew!
so as per comment 9 seems to be solved. Also this seems more of a support request as is -- if this should be a proper bug report, it needs clearcut reproduction instructions => NEEDINFO for now, likely to be closed INVALID without further info.
Given that the problem has been happening since version 3.3, and is quite serious when it occurs, it's disappointing that you're planning to resolve it once again. Are the stack backtraces not helpful? Is it possible that the mouse input event stream is getting connected to something weird? or could you implement some sort of signal that could be sent to LO to reset things so that you can at least reliably recover when it happens?
If it's any help, LO just locked up again, without any warning, as I was writing away. I was editing two files: WildThing-Bk1-Dave-delComms-1stHalf.odt WildThing-CS.odt but very actively typing into WildThing-CS.odt. Again, all interaction stopped. I did a ps and got this result, strangely: $ ps ax | grep off 17933 pts/4 S+ 0:00 grep off 32513 pts/4 Sl 0:00 /opt/libreoffice5.0/program/oosplash WildThing-Bk1-Dave-delComms-1stHalf.odt 32549 pts/4 Rl 117:27 /opt/libreoffice5.0/program/soffice.bin WildThing-Bk1-Dave-delComms-1stHalf.odt --splash-pipe=5 Why would the splash screen be active? Anyway, I took a guess that eventually it would work a little, if I waited long enough, and hit Ctrl-S and waited perhaps 5 or 10 mins. soffice did not appear in "top" output during this period. After thsi time, I saw the save progress bar progress partly across the bottom of the mis-drawn LO document window. The timestamp on the file in my directory shows that the Save has not completed, however. Also worryingly, the backup directory appears to be empty: $ ls -la ~/.config/libreoffice/4/user/backup/ total 40 drwxrwx--x 2 luke kendall 4096 Oct 29 19:47 . drwxrwx--x 14 luke kendall 4096 Oct 29 19:47 .. -rw------- 1 luke kendall 32748 Oct 29 17:08 CreateSpace5x8TemplateDoc.odt_0.odt ... despite auto-saves happening through the day. "top" is currently showing this: top - 19:55:03 up 98 days, 23:31, 15 users, load average: 1.42, 1.29, 0.96 Tasks: 266 total, 4 running, 261 sleeping, 0 stopped, 1 zombie %Cpu(s): 33.0 us, 0.9 sy, 0.0 ni, 66.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 16101596 total, 14913308 used, 1188288 free, 2187648 buffers KiB Swap: 9820156 total, 1088236 used, 8731920 free. 6592728 cached Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 32549 luke 20 0 2693604 495572 55924 R 100.0 3.1 127:58.88 soffice.bin 15372 luke 20 0 3015924 1.244g 53300 R 21.3 8.1 608:48.94 firefox ... Attaching to the running soffice process with gdb gives this backtrace: (gdb) where #0 0x00007fa8aae36dc6 in OutputDevice::LogicToPixel(Rectangle const&) const () from /opt/libreoffice5.0/program/libmergedlo.so #1 0x00007fa884853b7b in SwPageFrm::GetBorderAndShadowBoundRect(SwRect const&, SwViewShell const*, OutputDevice*, SwRect&, bool, bool, bool) () from /opt/libreoffice5.0/program/../program/libswlo.so #2 0x00007fa884853e0a in SwPageFrm::GetBoundRect(OutputDevice*) const () from /opt/libreoffice5.0/program/../program/libswlo.so #3 0x00007fa884cc24b7 in SwPageBreakWin::UpdatePosition(Point const*) () from /opt/libreoffice5.0/program/../program/libswlo.so #4 0x00007fa884cc039e in SwFrameControlsManager::SetPageBreakControl(SwPageFrm const*) () from /opt/libreoffice5.0/program/../program/libswlo.so #5 0x00007fa8848520bc in SwPageFrm::PaintBreak() const () from /opt/libreoffice5.0/program/../program/libswlo.so #6 0x00007fa884868e37 in SwRootFrm::Paint(OutputDevice&, SwRect const&, SwPrintData const*) const () from /opt/libreoffice5.0/program/../program/libswlo.so #7 0x00007fa884b765d1 in SwViewShell::Paint(OutputDevice&, Rectangle const&) () from /opt/libreoffice5.0/program/../program/libswlo.so #8 0x00007fa8845deccb in SwCrsrShell::Paint(OutputDevice&, Rectangle const&) () from /opt/libreoffice5.0/program/../program/libswlo.so #9 0x00007fa884cee16b in SwEditWin::Paint(OutputDevice&, Rectangle const&) () from /opt/libreoffice5.0/program/../program/libswlo.so #10 0x00007fa8aacc04bc in PaintHelper::DoPaint(vcl::Region const*) () from /opt/libreoffice5.0/program/libmergedlo.so #11 0x00007fa8aacc078b in vcl::Window::ImplCallPaint(vcl::Region const*, unsigned short) () from /opt/libreoffice5.0/program/libmergedlo.so #12 0x00007fa8aacc08af in PaintHelper::~PaintHelper() () from /opt/libreoffice5.0/program/libmergedlo.so #13 0x00007fa8aacc0744 in vcl::Window::ImplCallPaint(vcl::Region const*, unsigned short) () from /opt/libreoffice5.0/program/libmergedlo.so #14 0x00007fa8aacc08af in PaintHelper::~PaintHelper() () from /opt/libreoffice5.0/program/libmergedlo.so #15 0x00007fa8aacc0744 in vcl::Window::ImplCallPaint(vcl::Region const*, unsigned short) () from /opt/libreoffice5.0/program/libmergedlo.so #16 0x00007fa8aacc08af in PaintHelper::~PaintHelper() () from /opt/libreoffice5.0/program/libmergedlo.so #17 0x00007fa8aacc0744 in vcl::Window::ImplCallPaint(vcl::Region const*, unsigned short) () from /opt/libreoffice5.0/program/libmergedlo.so #18 0x00007fa8aacc08af in PaintHelper::~PaintHelper() () from /opt/libreoffice5.0/program/libmergedlo.so #19 0x00007fa8aacc0744 in vcl::Window::ImplCallPaint(vcl::Region const*, unsigned short) () from /opt/libreoffice5.0/program/libmergedlo.so #20 0x00007fa8aacc08af in PaintHelper::~PaintHelper() () from /opt/libreoffice5.0/program/libmergedlo.so #21 0x00007fa8aacc0744 in vcl::Window::ImplCallPaint(vcl::Region const*, unsigned short) () from /opt/libreoffice5.0/program/libmergedlo.so #22 0x00007fa8aacc0a5e in vcl::Window::ImplCallOverlapPaint() () from /opt/libreoffice5.0/program/libmergedlo.so #23 0x00007fa8aacc20a0 in vcl::Window::ImplHandlePaintHdl(Idle*) () from /opt/libreoffice5.0/program/libmergedlo.so #24 0x00007fa8aaf610bf in ImplSchedulerData::Invoke() () from /opt/libreoffice5.0/program/libmergedlo.so #25 0x00007fa8aaf6122f in Scheduler::ProcessTaskScheduling(bool) () from /opt/libreoffice5.0/program/libmergedlo.so #26 0x00007fa8aaf6e400 in Application::Yield() () from /opt/libreoffice5.0/program/libmergedlo.so #27 0x00007fa8aaf6e4b5 in Application::Execute() () from /opt/libreoffice5.0/program/libmergedlo.so #28 0x00007fa8aa080a33 in desktop::Desktop::Main() () from /opt/libreoffice5.0/program/libmergedlo.so #29 0x00007fa8aaf73729 in ImplSVMain() () from /opt/libreoffice5.0/program/libmergedlo.so #30 0x00007fa8aaf73772 in SVMain() () from /opt/libreoffice5.0/program/libmergedlo.so #31 0x00007fa8aa09f8a2 in soffice_main () from /opt/libreoffice5.0/program/libmergedlo.so #32 0x000000000040075b in main () I'll leave it for a while (having detached from it in gdb), with another Ctrl-S, and hope that over the next hour or two it gets enough time slice to save my work. With the backup directory empty, I'm worried I'll have lost 20 mins of intense creative work. :-(
Well, I waited over 90 mins, but it never saved the file. In the end I had to kill it and restart. As expected, from the lack of save files in the backup directory, kit also failed to recover them, and resorted to "the original file". Fortunately, because I realised immediately that LO had locked up, I took a screenshot of what was visible before anything obscured the window and hid the new text. That meant that I didn't lose any of my work, I just had to re-type it in. This seems like a very serious bug to me, even if it is not easily reproduced. It would be good if one or more of the stack backtraces helped someone work out what was going wrong.
Had been editing for about 30 mins, and suddenly LO stopped responding. Itook a screenshot of the window so at least I can retype what I've done when I restart it, since the beahviour is a repeat of the last lock-up. Top shows soffice.bin around 99.7 to 100% CPU. Here's the stack backtrace from gdb: looks very similar to last time: (gdb) where #0 0x00007f85e4f3f5eb in XCheckIfEvent () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #1 0x00007f85d4ea4e1f in X11SalInstance::AnyInput(VclInputFlags) () from /opt/libreoffice5.0/program/libvclplug_genlo.so #2 0x00007f85aea867ed in SwLayoutFrm::Paint(OutputDevice&, SwRect const&, SwPrintData const*) const () from /opt/libreoffice5.0/program/../program/libswlo.so #3 0x00007f85aea86682 in SwLayoutFrm::Paint(OutputDevice&, SwRect const&, SwPrintData const*) const () from /opt/libreoffice5.0/program/../program/libswlo.so #4 0x00007f85aea8d8cf in SwRootFrm::Paint(OutputDevice&, SwRect const&, SwPrintData const*) const () from /opt/libreoffice5.0/program/../program/libswlo.so #5 0x00007f85aed9b5d1 in SwViewShell::Paint(OutputDevice&, Rectangle const&) () from /opt/libreoffice5.0/program/../program/libswlo.so #6 0x00007f85ae803ccb in SwCrsrShell::Paint(OutputDevice&, Rectangle const&) () from /opt/libreoffice5.0/program/../program/libswlo.so #7 0x00007f85aef1316b in SwEditWin::Paint(OutputDevice&, Rectangle const&) () from /opt/libreoffice5.0/program/../program/libswlo.so #8 0x00007f85e91c44bc in PaintHelper::DoPaint(vcl::Region const*) () from /opt/libreoffice5.0/program/libmergedlo.so #9 0x00007f85e91c478b in vcl::Window::ImplCallPaint(vcl::Region const*, unsigned short) () from /opt/libreoffice5.0/program/libmergedlo.so #10 0x00007f85e91c48af in PaintHelper::~PaintHelper() () from /opt/libreoffice5.0/program/libmergedlo.so #11 0x00007f85e91c4744 in vcl::Window::ImplCallPaint(vcl::Region const*, unsigned short) () from /opt/libreoffice5.0/program/libmergedlo.so #12 0x00007f85e91c48af in PaintHelper::~PaintHelper() () from /opt/libreoffice5.0/program/libmergedlo.so #13 0x00007f85e91c4744 in vcl::Window::ImplCallPaint(vcl::Region const*, unsigned short) () from /opt/libreoffice5.0/program/libmergedlo.so #14 0x00007f85e91c48af in PaintHelper::~PaintHelper() () from /opt/libreoffice5.0/program/libmergedlo.so #15 0x00007f85e91c4744 in vcl::Window::ImplCallPaint(vcl::Region const*, unsigned short) () from /opt/libreoffice5.0/program/libmergedlo.so #16 0x00007f85e91c48af in PaintHelper::~PaintHelper() () from /opt/libreoffice5.0/program/libmergedlo.so #17 0x00007f85e91c4744 in vcl::Window::ImplCallPaint(vcl::Region const*, unsigned short) () from /opt/libreoffice5.0/program/libmergedlo.so #18 0x00007f85e91c48af in PaintHelper::~PaintHelper() () from /opt/libreoffice5.0/program/libmergedlo.so #19 0x00007f85e91c4744 in vcl::Window::ImplCallPaint(vcl::Region const*, unsigned short) () from /opt/libreoffice5.0/program/libmergedlo.so #20 0x00007f85e91c4a5e in vcl::Window::ImplCallOverlapPaint() () from /opt/libreoffice5.0/program/libmergedlo.so #21 0x00007f85e91c60a0 in vcl::Window::ImplHandlePaintHdl(Idle*) () from /opt/libreoffice5.0/program/libmergedlo.so #22 0x00007f85e94650bf in ImplSchedulerData::Invoke() () from /opt/libreoffice5.0/program/libmergedlo.so #23 0x00007f85e946522f in Scheduler::ProcessTaskScheduling(bool) () from /opt/libreoffice5.0/program/libmergedlo.so #24 0x00007f85e9472400 in Application::Yield() () from /opt/libreoffice5.0/program/libmergedlo.so #25 0x00007f85e94724b5 in Application::Execute() () from /opt/libreoffice5.0/program/libmergedlo.so #26 0x00007f85e8584a33 in desktop::Desktop::Main() () from /opt/libreoffice5.0/program/libmergedlo.so #27 0x00007f85e9477729 in ImplSVMain() () from /opt/libreoffice5.0/program/libmergedlo.so #28 0x00007f85e9477772 in SVMain() () from /opt/libreoffice5.0/program/libmergedlo.so #29 0x00007f85e85a38a2 in soffice_main () from /opt/libreoffice5.0/program/libmergedlo.so #30 0x000000000040075b in main () There were 4 files it needed to recover: as usual, despite the autosave kicking in at regular intervals, I got errors like this: /home/luke/.config/libreoffice/4/user/backup/WildThing-CS.odt_0.odt does not exist $ ls -la /home/luke/.config/libreoffice/4/user/backup/ total 8 drwxrwx--x 2 luke kendall 4096 Nov 5 11:56 . drwxrwx--x 14 luke kendall 4096 Nov 5 12:05 .. By the way, I should thank whoever implemented the reworking of the event handling so that typing during the autosave is correctly buffered and applied when the autosave finishes, instead of being lost as it used to be. Incidentally, at the end of the automatic recovery process, it presesnts a confusing summary window. It said: The automatic recovery process was interrupted. [It wasn't: perhaps it means it didn't complete for some reason?] The documents listed below will be saved in the folder noted below if you click 'Save'. Click 'Cancel' to close the wizard without saving the documents. Documents: [the 4 docs listed] Save to: /home/luke So, I chose Save, and as I expected from past behaviour, the files were not saved in /home/luke. In addition, the Save menu item on the File menu was grayed out. I could choose Save As, and save it back over the top of the existing file, or navigate to /home/luke to save it there if I wished, but that wasn't the default option. So the panel that popped up seems very unclear to me. I can't understand in what sense the "files were saved to /home/luke", as that didn't happen, nor was it the default option in any sense. The screenshot was necessary: otherwise I would have lost 30 mins of work.
BTW, I've submitted bug 95591 regarding the autosave problem, as that's clearly a separate issue.
I just did a software update (under Ubuntu 14.04), which included an update for the lib UNO component. I had left LO idle for 2.5 hrs, and had not been actively editing any files. When I opened the window, I saw it had locked up again and "top" showed it once again using around 155% CPU time. Here's the stack backtrace from gdb this time: (gdb) where #0 0x00007fc6eab20190 in PhysicalFontFamily::AddFontFace(PhysicalFontFace*) () from /opt/libreoffice5.0/program/libmergedlo.so #1 0x00007fc6eab1f600 in PhysicalFontCollection::Add(PhysicalFontFace*) () from /opt/libreoffice5.0/program/libmergedlo.so #2 0x00007fc6eab54654 in FreetypeManager::AnnounceFonts(PhysicalFontCollection*) const () from /opt/libreoffice5.0/program/libmergedlo.so #3 0x00007fc6eab7fe78 in CairoTextRender::GetDevFontList(PhysicalFontCollection*) () from /opt/libreoffice5.0/program/libmergedlo.so #4 0x00007fc6ea973798 in OutputDevice::ImplRefreshFontData(bool) () from /opt/libreoffice5.0/program/libmergedlo.so #5 0x00007fc6ea9736cd in OutputDevice::ImplRefreshFontData(bool) () from /opt/libreoffice5.0/program/libmergedlo.so #6 0x00007fc6ea9736cd in OutputDevice::ImplRefreshFontData(bool) () from /opt/libreoffice5.0/program/libmergedlo.so #7 0x00007fc6ea9736cd in OutputDevice::ImplRefreshFontData(bool) () from /opt/libreoffice5.0/program/libmergedlo.so #8 0x00007fc6ea9736cd in OutputDevice::ImplRefreshFontData(bool) () from /opt/libreoffice5.0/program/libmergedlo.so #9 0x00007fc6ea9736cd in OutputDevice::ImplRefreshFontData(bool) () from /opt/libreoffice5.0/program/libmergedlo.so #10 0x00007fc6ea9736cd in OutputDevice::ImplRefreshFontData(bool) () from /opt/libreoffice5.0/program/libmergedlo.so #11 0x00007fc6ea973ff9 in OutputDevice::ImplUpdateFontDataForAllFrames(void (OutputDevice::*)(bool), bool) () from /opt/libreoffice5.0/program/libmergedlo.so #12 0x00007fc6ea97682c in OutputDevice::ImplUpdateAllFontData(bool) () from /opt/libreoffice5.0/program/libmergedlo.so #13 0x00007fc6ea8dde73 in ImplWindowFrameProc(vcl::Window*, SalFrame*, unsigned short, void const*) () from /opt/libreoffice5.0/program/libmergedlo.so #14 0x00007fc6eab36688 in SalGenericDisplay::DispatchInternalEvent() () from /opt/libreoffice5.0/program/libmergedlo.so #15 0x00007fc6d7b2e0e9 in GtkData::userEventFn(void*) () from /opt/libreoffice5.0/program/libvclplug_gtklo.so #16 0x00007fc6d7b2e161 in call_userEventFn () from /opt/libreoffice5.0/program/libvclplug_gtklo.so #17 0x00007fc6e3dcece5 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #18 0x00007fc6e3dcf048 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #19 0x00007fc6e3dcf0ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #20 0x00007fc6d7b2d4d3 in GtkData::Yield(bool, bool) () from /opt/libreoffice5.0/program/libvclplug_gtklo.so #21 0x00007fc6eaacc433 in Application::Yield() () from /opt/libreoffice5.0/program/libmergedlo.so #22 0x00007fc6eaacc4b5 in Application::Execute() () from /opt/libreoffice5.0/program/libmergedlo.so #23 0x00007fc6e9bdea33 in desktop::Desktop::Main() () from /opt/libreoffice5.0/program/libmergedlo.so #24 0x00007fc6eaad1729 in ImplSVMain() () from /opt/libreoffice5.0/program/libmergedlo.so #25 0x00007fc6eaad1772 in SVMain() () from /opt/libreoffice5.0/program/libmergedlo.so #26 0x00007fc6e9bfd8a2 in soffice_main () from /opt/libreoffice5.0/program/libmergedlo.so #27 0x000000000040075b in main () I was literally about to kill LO, but it suddenly started behaving normally again, CPU use less than 10%.
And it just happened again - shortly after an Undo operation. (Sorry, this happened about 4 days ago - I only just now realised I hadn't saved this.) Here's the stack backtrace this time. Shortest one I've seen for this problem: (gdb) where #0 0x00007fe62692812d in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007fe622c60fe4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007fe622c610ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007fe6169be4d3 in GtkData::Yield(bool, bool) () from /opt/libreoffice5.0/program/libvclplug_gtklo.so #4 0x00007fe62995e433 in Application::Yield() () from /opt/libreoffice5.0/program/libmergedlo.so #5 0x00007fe62995e4b5 in Application::Execute() () from /opt/libreoffice5.0/program/libmergedlo.so #6 0x00007fe628a70a33 in desktop::Desktop::Main() () from /opt/libreoffice5.0/program/libmergedlo.so #7 0x00007fe629963729 in ImplSVMain() () from /opt/libreoffice5.0/program/libmergedlo.so #8 0x00007fe629963772 in SVMain() () from /opt/libreoffice5.0/program/libmergedlo.so #9 0x00007fe628a8f8a2 in soffice_main () from /opt/libreoffice5.0/program/libmergedlo.so #10 0x000000000040075b in main ()
I upgraded to 5.0.3.3 yesterday. It happened again today. Attached is a screenshot (FWIW) and anothe stack backtrace, below: (gdb) where #0 0x00007f24cf2fe12d in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007f24cb636fe4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007f24cb6370ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007f24bf3944d3 in GtkData::Yield(bool, bool) () from /opt/libreoffice5.0/program/libvclplug_gtklo.so #4 0x00007f24d2336313 in Application::Yield() () from /opt/libreoffice5.0/program/libmergedlo.so #5 0x00007f24d2336395 in Application::Execute() () from /opt/libreoffice5.0/program/libmergedlo.so #6 0x00007f24d1447f13 in desktop::Desktop::Main() () from /opt/libreoffice5.0/program/libmergedlo.so #7 0x00007f24d233b609 in ImplSVMain() () from /opt/libreoffice5.0/program/libmergedlo.so #8 0x00007f24d233b652 in SVMain() () from /opt/libreoffice5.0/program/libmergedlo.so #9 0x00007f24d1466d82 in soffice_main () from /opt/libreoffice5.0/program/libmergedlo.so #10 0x000000000040075b in main () On this occasion, I had just modified a comment and a sentence (after leaving the documents open overnight), and the tried to search for a word. The search text box did not refresh correctly, though otherwise things seemed normal. But as I continued to try to do my search, I could not make the text appear in the search box (for the word I was looking for), though the cursor (text insertion point) did appear where it should. I saved the file via a Ctrl-S. But gradually, more and more of the refresh broke. The screenshot was at the point where I couldn't get any of the drop-down menus to display; as is the stack trace, above. The comment mod was perhaps odd: I copied a sentence with its attached comment, into the body of that same comment (so I could say: "This is how the sentence used to read"). But, I just now tried that same sequence to see if I could reproduce the bug, but it was all fine.
It just happened again. This is on a fresh install of a development version of Ubuntu (16.04), with the (urgh) Unity UI, and LO 5.0.3.2. I had just added a comma after some superscript caps, then backspaced over it (since I didn't want tthe comma in supoerscript), and the comma did not disappear. I think I then tried Undo, and the cursor moved to an odd position and the comma was still there. I used Undo again, then realised the refresh did not match the operations I was performing. I used Redo to get to the end, then hit Ctrl-S. A Save panel appeared, but the panel was not rendered correctly (ut had the text background). I clicked on the File menu, and its' contents were not rendered, thought the drop shadow was. When I hovered over an entry, a sub-menu appeared to the right, also not rendered (though its drop shadow was), but when I moved the cursor to the left, the File menu was then rendered (menu to the right was still not rendered). I'll attach some screenshots in the attachment LO-Menu-refresh-fail.zip. Quitting all open documents and re-opening them in LO put it back into normal mode.
Created attachment 122031 [details] Three screenshots of different states of the failed redraws This is the attachment LO-Menu-refresh-fail.zip for the previous comment.
I have the same problem. GUI is LDX which may have something to do with it. Ubuntu 16.04
Using Ubuntu 16.04 and LDX Saving, closing and reopening solves the problem. It seems to be a feature of certain documents.
Did you try with 5.1.2?
(In reply to Buovjaga from comment #23) > Did you try with 5.1.2? I'm certainly using 5.1.2.2 now; and I've been good about taking the new versions as soon as they're available for Ubuntu 16.04: so how long would that be? But so far it's not happened. At least, not globally, across the whole UI. The most I've seen is the Font, Font size, or Paragraph style menus go blank, with no items present, and that's different behaviour: when this bug occurs, you don't get any menus dropping down at all. So basically what I'm reporting is that it has not yet recurred in 5.1.2.2.
Henry: what GUI is LDX? Do you mean LXDE? Do you use LibreOffice 5.1.2?
@Henry please give feedback and tell if issue persists with latest LibO 5.1.2.2 release.+ NEEDINFO until then
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-20170502
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-20170531