Created attachment 125642 [details] samples of process activity during freeze When you are working on a Libreoffice document if you launch or close a session of IBM iSeries Client Access (pscws.exe) the Libreoffice windows freeze for 10s to 2mn (seems to depend of the computer power) moreover it may sometime freeze forever. Noticed on win10, w2008 and w2012 for x32 and x64 Libreoffice 5.0.3 also affected IBM iSeries Client Access version 6.0 In the attachment, I have included samples of soffice.bin process activity during the freeze : two screen captures of ProcessHacker and an export of Sysinternal procmon
So don't run the iSeries Client Access? Looking in the Process Monitor log is showing registry queries to HKLM\Software\Microsoft\PolicyManager\default\DataProtection\EDPEnforcementLevel and assume this is only happening while the iSeries Client Access is running. So EDP is being activated with iSeries Client Access. If that is the case, then the issue is caused by a policy set for your company EDP implementation, and the iService Client Access implements it. LibreOffice is NOT an EDP aware application, but IIUC could be added as a "Classic" Windows program. Beyond that, you need to check in with your IT types about the role of IBM iSeries Client Access, the EDP policies, and if LibreOffice can be allowed. =-ref-= https://msdn.microsoft.com/en-us/library/mt589520.aspx https://technet.microsoft.com/en-us/itpro/windows/keep-secure/create-edp-policy-using-sccm
Created attachment 125650 [details] Call stack of process soffice.bin main thread A few peek on the call stack from process soffice.bin main thread during a freeze
(In reply to V Stuart Foote from comment #1) I don't think that EDP is tied to our freeze problem. indeed, in a system with Libreoffice launched with an opened document and NO iSeries Client Access this bunch of registry queries on EDP keys occurs every 5 mn without any freeze. Moreover, in the Process Monitor log these queries start 95 seconds after the start of the freeze
Hmm, not a clue then. However, you might find it helpful to install the Debugging tools from a MS SDK (either 8.1 or 10), set the Symbol path and then break into the program to catch a stack trace with the symbols. The slices in your stacktrace are incomplete. Using WinDbg and manually stepping through with symbols linked should give you more useable traces with associated line numbering in the code. =-ref-= https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg
Created attachment 126024 [details] backtrace : !analyze -v result in windbg
Install and use of windbg from SDK10 is not straigthforward, especialy behind corporate proxy with authentication As there is no crash but only a freeze, i've done "break" during the freeze to get back control in windbg before executing the !analyze -v
Since there is no "crash" there is nothing that an "!analyse -v" to reveal. Rather, bring the LibreOffice session close to where you'd like it, and then attach the soffice.bin process to the WinDbg utility. Check the symbol source is pointing to the LibreOffice symbol servers as in the Wiki. run a "lml" command, and then a "~*kp" stack trace for all threads-- this loads symbols, updating any that are not yet cached locally. Issue a "g" command to be sure LibreOffice is running, then open your IBM iSeries Client Access (pscws.exe), if it hangs LibreOffice in the WinDbg console take a "~*kp" stack trace and allow any additional symbols to load. Or, if need break into LibreOffice (from Debug -> Break menu) and then run the stack trace with "~*kp" See if anything interesting shows in any of the threads. Of course you can also attach to the pscws.exe or one of its processes as well--but not sure where you'd find useful symbols to the program and would only have MicroSoft's.
Created attachment 126081 [details] All threads stack trace - before and during freeze Here is the result of windbg command "~*kp" on soffice.bin process before and during the freeze (break needed to get back control of windbg). A diff beetween "before" and "during" show 4 changes in the list : - thread 0 (soffice!main) : big increase of the stack length (from 13 to 32 rows) but I can't tell if there is something abnormal here, apart for same call repeated 8th time (rows 8 to 15) that seems a bit strange. - thread 7 : Id differs (the old thread ended and a new one started) - thread 11 : row 3 of the stack, values of pParam have changed - thread 14 : no longer present during freeze, but seems to be windbg related
Same problem here, we have four win10 machines, all affected by the issue. I installed some older versions of libreoffice to find out which one introduced that bug. But the freeze seems to get longer on every release, there's no clear culprit unfortunately : 4.0.0.3 ok, no freeze or maybe less than a second 4.2.0.4 ok, '' 4.2.6.1 ok, '' 4.2.8.1 freeze 2 sec 4.3.0.1 freeze 5 sec 4.4.0.1 freeze 8 sec 5.0.0.1 freeze 15 sec 5.3.0.0alpha freeze 30 sec
I can comfirm this bug in LibreOffice 5.0.x, 5.1.x and 5.2.2 under Windows 7 SP1, on different hardware. We use IBM i Access Version 7, Release 1, Mod. 0 Service-Level SI60523 (the newest one).
Setting to NEW per previous comments.
this is interesting: 10 0000001c`b2baf200 00007ffe`20b3b3d0 mergedlo!OutputDevice::ImplUpdateFontDataForAllFrames(<function> * pHdl = 0x00000000`00000012, bool bNewFontLists = true)+0x49 [c:\cygwin64\home\buildslave\source\libo-core\vcl\source\outdev\font.cxx @ 644] presumably this iSeries application registers some custom fonts with Windows? Caolan, did you fix similar font-enumeration performance issues with GTK recently?
The thing I fixed recently was https://cgit.freedesktop.org/libreoffice/core/commit/?id=ef7abe81df10cb8a8c04afbb1fbe700f94e73f04 which reduces the amount of times the font settings are thrown away and refetched if we receive a style-changed settings which suggests that app font settings need updating
The ibm emulator sends a dozen of "WM_FONTCHANGE" every time I open or close a window. And Libreoffice does a lot of work on each of those messages. As a workaround, you can remove all the fonts from "IBM\Client Access\Emulator" (ttf and fon files) (moving the fonts to "windows\fonts" doesn't work either, the emulator keep sending the messages) Removing the IBM fonts is not ideal and I get weird characters here and there, but I can work with that.
Any news about this ? The problem exist also in Version 6.0.0.3 (x64) Windows 10. I have the latest Service Packs from IBM for Client Access V7 installed. https://www-03.ibm.com/systems/power/software/i/access/windows_sp.html
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Noticing commits like https://cgit.freedesktop.org/libreoffice/core/commit/?id=37e3573bb5739c94890c18ed11b4f4cc8a4df67f, could you give a try at a daily build (see https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/current/)? Of course, it's just for test since they correspond to future 6.5.0 version. You may first give a try to last stable LO version 6.3.4.
I just tried the LibreOfficeDev_7.0.0.0.alpha0_Win_x64.msi : same behavior. Replacing the two occurrences of "6a 00 6a 00 6a 1d 68 ff ff 00 00 ff 15 9c 50 8d 67" by "6a 00 6a 00 6a 00 68 ff ff 00 00 ff 15 9c 50 8d 67" in "client access/emulator/pcsfont.dll" would be illegal. so don't do it... but it would disable the WM_FONTCHANGE broadcasts and fix the issue. I guess AddFontResource, RemoveFontResource and WM_FONTCHANGE are more often used by installers ? If the IBM 5250 emulator is the only program that registers fonts every time it starts, we have a fix, and other 5250 emulators are available. But the problem could reappear randomly with other applications. Maybe Libreoffice should ignore the WM_FONTCHANGE broadcasts if it freezes for 30 seconds ? Restarting libroffice when I install new fonts wouldn't be an issue to me, but maybe in some other use cases ?
So, with LibreOffice running--the WM_FONTCHANGE from the IBM Client Access (pscws.exe) triggers the salframe.cxx -> bNewFontLists action. Could handling of the ImplHandleSettingsChangeMsg [1] for the WM_FONTCHANGE case be tweaked to ignore response to a terminal emulator like this? =-ref-= [1] https://opengrok.libreoffice.org/xref/core/vcl/win/window/salframe.cxx?r=cba20762#5778
@Mike K. might be of interest to you...
Dear Patrick, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug