In any sized document with any amount of text, attempts to insert or edit the index or table of contents of documents result in the program freezing and the process and application to enter the "Not Responding" state. Closing the window will bring up a dialog box asking if I would like to end the process. This happens regardless of document - new, old, doesn't matter, it will affect it. The same issue occurs when attempting to edit a Style, whether that style is new or preexisting. It should be noted that I encountered the exact same error with almost the exact same peramaters in Apache Open Office version 4.1.2. I was able to get the Style Editing window to appear and briefly play with it before the program hung. I uninstalled and reinstalled the program several times hoping to fix the issue, but it persists, in both the stable 5.0.0.5 release update and the rolling release version 5.1.1.3. On Windows 7 64-bit Ultimate Editiion license, that is as far as I know up-to-date on all code available for it. Hardware is: Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz 16.0 BG RAM NVIDIA GeForce GTX 980 with 11851 MB of VRAM 4 Drives attached to the system (2 SSDs (one 466G(That's C:\) the other 117G) and two HDDs (Both 1863G) Two Optical Drives (one is virtual) And a 16G Flash Drive is also plugged into the computer, but I don't think that matters too much.
Hello, For the test, could you rename your LibreOffice directory profile (see https://wiki.documentfoundation.org/UserProfile) and give it a new try?
(In reply to raal from comment #1) > Hello, > For the test, could you rename your LibreOffice directory profile (see > https://wiki.documentfoundation.org/UserProfile) and give it a new try? I didn't before you mentioned it, but I have now, and it has had no effect. However, for some reason, I am able to make Indexes, Table of Contents, and Edit Styles after a reboot of the system. That said, there is still a lengthy bit of time where the program freezes and becomes non-responsive. It's just that now, it eventually breaks out of the freeze with the corresponding dialog box to my actions. The freeze lasts maybe two, three minutes on average now, and I know I waited longer than that before terminating the process previously. No longer a "completely unable to work" issue at least, but still a "takes longer than it really should" problem.
There is definitely something weird going on, but hard to say what. Maybe try with a fresh dev build: http://dev-builds.libreoffice.org/daily/master/Win-x86@42/current/ It installs separately.
Different Bugzilla user with a confirming instance this issue: Windows 8.1 Pro Version 6.3.9600 Build 9600 with MS patches through 30 May 2016. Processor: Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz, 2201 Mhz, 4 Core(s), 8 Logical Processor(s) LO Version: 5.1.2.2 (x64) Build ID: d3bf12ecb743fc0d20e0be0c58ca359301eb705f. LO Writer Insert TOC window comes up no issue but any mouse action in the window, even only tab selection with no parameter actions, starts an apparent "not responding" freeze. However, Win Task Manger shows about 16%-19% CPU use on the 4-core processor, so clearly in a loop. LO application can be terminated via Win TM. Have not attempted to wait out the loop beyond abut 5 minutes. Consistently reproducible. Win 8.1 Pro Task Manager does offer the capability to create a dump file as part of the right-click context menu for a process. In my instance the subject doc file is a custom .ott in development and does not contain PII or proprietary data. Win TM shows about a 70 MB memory usage for this doc process.
I can not confirm with 5.1.3.2 (x64),win10. Please could you attach test file? thanks
Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the document.
Freezes when select a text either with mouse or keys - I see the market text and then it freezes. I can not do any action like cut/paste or format that I want to do.
Still not seeing a test file, so back to NEEDINFO.
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-20161207
Created attachment 129475 [details] Bug 99006 test .odt file Scratch created .odt using LO 5.2.2.3 x64 Win 10 Pro as follows: New -> Text Document Gives new blank text doc. Absolutely no text content added. Insert -> Table of Contents and Index -> Table of Contents, Index, or Bibliography... Object UI box appears then hangs at first mouse event in box.
This bug updated for LO release 5.2.3.3 x64 on Win 10 Pro. CPU Intel i7 with 16 GB RAM & SSD. TOC create or update hang symptoms continue. Win Task Manager shows LO consuming 16-18% CPU on an Intel i7, so TOC function in a loop somewhere. LO Functionality is useless, however, I have discovered a workaround: Use Apache OO 4.1.3 to create and update TOC and other objects created and maintained through the TOC/Index/Biblio UI. Apache codebase is therefore a comparative for where LO has run in to the ditch. Attached a test file to fill the NEEDINFO status. Note the comments attached to the test file: a completely new, empty .odt generates TOC creation hangs, so the test doc does *not* have a TOC!
R. Bingham and tooneyspam: can you please copy and paste here the contents of your Help - About box? It gives some useful info. I cannot reproduce the hang. I can insert a TOC and edit a style. Version: 5.4.0.0.alpha0+ Build ID: cb598029835477326b190bc99abd31a487cc5a91 CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2016-12-09_00:49:18 Locale: fi-FI (fi_FI); Calc: group
Per request, copy/paste of LO Help->About Version: 5.2.3.3 (x64) Build ID: d54a8868f08a7b39642414cf2c8ef2f228f780cf CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; Locale: en-US (en_US); Calc: group NEW INFO: The Win10 user in my test situation for which the TOC function hang occurs is non-privileged - does not have Administrator privileges. I just tested TOC insertion in a new blank .odt as a privileged user and it works! I apologize for not thinking of this earlier. This finding suggests several items: Testing by the LO team may have overlooked the Windows security context of the test_user login profile as an important hidden assumption. I suggest that test_user should always *not* have Windows Administrator privilege. Testing with privilege hides permissions related bugs in operation. Install as Administrator but test standard functionality as unprivileged. The TOC hang is probably permissions related. For example, LO may be trying to perform operations in its install directory tree in the Windows 'Program Files' directory that are denied to unprivileged users. The spin at 16-18% CPU suggests an error return is not being checked at lower levels in the code and so it loops. R
(In reply to R. Bingham from comment #13) > Testing by the LO team may have overlooked the Windows security context of > the test_user login profile as an important hidden assumption. I suggest > that test_user should always *not* have Windows Administrator privilege. > Testing with privilege hides permissions related bugs in operation. Install > as Administrator but test standard functionality as unprivileged. Well, by coming here you are now part of "the LO team" ;) I created a "Standard account" and tested: no problem with any hangs, can still go to TOC and edit a style. Tooneyspam: any insight from you? Let's set this to NEW in any case.
Tested on another Win10 x64 image available (HP laptop factory Win10 Pro image) and TOC creation worked for an unprivileged user. My original additions to this bug where on HP hardware but the Win images where built from MS System Builder install (Win 8.1) or the MS Win10 migration from that, so not typical consumer images supplied with hardware by manufacturers. Still smells like a permissions issue that in turn reveals some failed or non-existent error recovery in the code. So, need instruction for LO builtin diag or a recommendation for a tool to capture LO process state and/or stack dump while it is spinning or use the Win Task Manager Dump File function to post something to Bugzilla for interpretation. R
(In reply to R. Bingham from comment #15) > some failed or non-existent error recovery in the code. So, need > instruction for LO builtin diag or a recommendation for a tool to capture LO > process state and/or stack dump while it is spinning or use the Win Task > Manager Dump File function to post something to Bugzilla for interpretation. You could try WinDbg: https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg When it hangs, you could try giving this command in WinDbg: ~* kp Note: I'm not a Win debugging guru.
Hmmm... the referenced Wiki article is almost entirely about capturing and analyzing crash events. What we have here is a hang (Windows spinner and un-responsive window from the user's POV) with elevated CPU consumption, not a crash. The Wiki article does not contain the word 'hang' but does have a section on producing a mini-dump for analysis by WinDbg using the MS tool ProcDump (http://technet.microsoft.com/en-us/sysinternals/dd996900). However, the instructions for ProcDump in the Wiki article are thin and ProcDump has 26 option flags. Perhaps if a Windows person could take a quick look at the ProcDump man page on MS Technet and update the Wiki with a recommended ProcDump option set to get the the most value when capturing a x64 LO Writer mini-dump. I also suggest the word 'hang' be included in the ProcDump section of the Wiki article. Let me know, R
The command ~* kp can be used with hangs, that is why I suggested it.
Created attachment 129752 [details] WinDbg analyze listing of soffice.bin dump file by Task Manager Underlying Windows dump file created using Task Manager dump file function on a running but unresponsive LO app instance rather than MS ProcDump as I have no detail instruction for ProcDump invocation parameters.
Win dump file captured using Task Manager on a running but unresponsive instance of LO Writer with a scratch new text doc and first command in Writer is Insert->TOC. Task Manager shows LO Writer consistent at ~17% CPU on a 4-core Intel i7. Security context is an *un*privileged user. Attached text file is a listing of the WinDbg !analyze -v command run against the dump file as a privileged user. Some items: + I used the symbol path list from the Wiki page copy/paste. Note WinDbg complains it could not find a symbol file but alas does not indicate which one. Someone please test the symbol data path given on the Wiki page as possibly stale. + I note in the listing FAULTING_SOURCE_LINE indicates use of Cygwin64 components in LO. I am running Cygwin64 daemons syslog-ng and cygserver on this machine, managed using the Windows/Computer Management/Service infrastructure. Is there any indication in the LO end-user doc of dependence on Cygwin or does the LO install or app startup test for an existing instance of Cygwin and version compatibility if the is important? I really, really, really suggest someone provide some detailed guidance for parameter choices for MS ProcDump if that will increase the value that can be extracted from a dump analysis. Note: The WinDbg command 'kp' merely lists a summary stack trace of a stopped process. One actually has to understand breakpoint debugging to know you have to stop the process in the first place. I have that listing as well but it is not that informative.
(In reply to R. Bingham from comment #20) > + I used the symbol path list from the Wiki page copy/paste. Note WinDbg > complains it could not find a symbol file but alas does not indicate which > one. Someone please test the symbol data path given on the Wiki page as > possibly stale. Your trace looks OK. It always complains about some symbol file being found, but if there is a real problem, there are more complaints. > + I note in the listing FAULTING_SOURCE_LINE indicates use of Cygwin64 > components in LO. I am running Cygwin64 daemons syslog-ng and cygserver on > this machine, managed using the Windows/Computer Management/Service > infrastructure. Is there any indication in the LO end-user doc of > dependence on Cygwin or does the LO install or app startup test for an > existing instance of Cygwin and version compatibility if the is important? There is not dependency on Cygwin. Cygwin is just used when building from source under Windows.
Win 10 Pro x64 build 1511 LO Version: 5.4.0.3 (x64) Build ID: 7556cbc6811c9d992f4064ab9287069087d7f62c CPU threads: 8; OS: Windows 6.19; UI render: GL; Locale: en-US (en_US); Calc: CL TOC insert and update under non-Admin Windows account seems fixed in LO 5.4.
Ok, let's close as WFM as tooneyspam seems to be ignoring this report anyway.