Bug 100362 - Libreoffice freeze when launching or closing IBM iSeries Client Access session
Summary: Libreoffice freeze when launching or closing IBM iSeries Client Access session
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
(earliest affected) rc
Hardware: x86-64 (AMD64) Windows (All)
: high major
Assignee: Not Assigned
Keywords: haveBacktrace
Depends on:
Blocks: Performance
  Show dependency treegraph
Reported: 2016-06-13 18:35 UTC by Patrick
Modified: 2023-04-12 16:59 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:

samples of process activity during freeze (95.23 KB, application/x-zip-compressed)
2016-06-13 18:35 UTC, Patrick
Call stack of process soffice.bin main thread (9.91 KB, application/vnd.oasis.opendocument.spreadsheet)
2016-06-14 12:23 UTC, Patrick
backtrace : !analyze -v result in windbg (19.64 KB, text/plain)
2016-07-01 13:44 UTC, Patrick
All threads stack trace - before and during freeze (43.55 KB, text/plain)
2016-07-05 16:58 UTC, Patrick

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick 2016-06-13 18:35:34 UTC
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
Comment 1 V Stuart Foote 2016-06-13 23:32:13 UTC
So don't run the iSeries Client Access?

Looking in the Process Monitor log is showing registry queries to
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.

Comment 2 Patrick 2016-06-14 12:23:50 UTC
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
Comment 3 Patrick 2016-06-14 12:25:19 UTC
(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
Comment 4 V Stuart Foote 2016-06-14 13:17:42 UTC
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.

Comment 5 Patrick 2016-07-01 13:44:02 UTC
Created attachment 126024 [details]
backtrace :  !analyze -v result in windbg
Comment 6 Patrick 2016-07-01 13:45:22 UTC
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
Comment 7 V Stuart Foote 2016-07-01 14:05:12 UTC
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.
Comment 8 Patrick 2016-07-05 16:58:32 UTC
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
Comment 9 Raphael etc. 2016-07-11 14:34:27 UTC
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 : ok, no freeze or maybe less than a second ok,           '' ok,           '' freeze 2 sec freeze 5 sec freeze 8 sec freeze 15 sec freeze 30 sec
Comment 10 AS 2016-09-30 05:38:16 UTC
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).
Comment 11 Buovjaga 2016-10-12 12:33:04 UTC
Setting to NEW per previous comments.
Comment 12 Michael Stahl (allotropia) 2016-10-12 12:39:38 UTC
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?
Comment 13 Caolán McNamara 2016-10-12 12:56:02 UTC
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
Comment 14 Raphael etc. 2017-11-24 13:36:36 UTC
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.
Comment 15 Michael Velten 2018-02-07 08:16:58 UTC
Any news about this ? The problem exist also in Version (x64) Windows 10. I have the latest Service Packs from IBM for Client Access V7 installed.

Comment 16 QA Administrators 2019-02-08 03:51:19 UTC Comment hidden (obsolete)
Comment 17 Julien Nabet 2020-01-22 16:25:02 UTC
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.
Comment 18 Raphael etc. 2020-04-14 15:10:23 UTC
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 ?
Comment 19 V Stuart Foote 2020-04-14 16:58:59 UTC
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? 

[1] https://opengrok.libreoffice.org/xref/core/vcl/win/window/salframe.cxx?r=cba20762#5778
Comment 20 V Stuart Foote 2020-04-14 17:00:58 UTC
@Mike K. might be of interest to you...
Comment 21 QA Administrators 2022-04-15 04:00:37 UTC
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