Bug 96310 - LO will hang for 30 plus seconds after opening EMR software alongside the LO suite (1 processor fully consumed)
Summary: LO will hang for 30 plus seconds after opening EMR software alongside the LO ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.3.0.4 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, haveBacktrace, regression
Depends on:
Blocks:
 
Reported: 2015-12-07 15:38 UTC by mwallinger
Modified: 2019-04-14 13:13 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Meditech and LO process stack (273.53 KB, image/jpeg)
2015-12-07 15:38 UTC, mwallinger
Details
backtrace log (13.46 KB, text/plain)
2015-12-09 15:34 UTC, mwallinger
Details
Backtrace force dump (8.14 KB, text/plain)
2015-12-09 15:35 UTC, mwallinger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mwallinger 2015-12-07 15:38:36 UTC
Created attachment 121110 [details]
Meditech and LO process stack

I have a strange issue with LO all the way back to 4.3 release that I was just made aware of (4.2 the issue does not occur with). No matter the hardware (VDI, Dell, HP, on 32 or 64 bit Windows 7) the LO application will consistently hang, not crash (no work is lost), (LO will not bring itself back to the foreground when clicking from taskbar once opening or closing Meditech EMR(alt tab does not bring the application forward either) for sometimes over 30 seconds. Once the timeout is complete the LO application comes back to life with zero issues. The LO application that is open (calc, writer, or impress (doesn't matter which LO application you use)) will always come to a halt after launching this other application (no error messages, nothing in the event viewer, windows debug reveals nothing once launching the other application). The LO application that was open is now a screen that is a painting of the application that was launched; you can move any other screen over the LO window and it will look like you won the solitaire game (screen painting). During this operation of hanging 1 processor will be consumed completely by soffice.bin. Once the application is unfrozen the processor activity goes back to a normal idle. If you launch the EMR software, then run LO there is no issue.

I have tried disabling OpenCL within the tools area; nothing changed in the way the application froze once the other application was launched. I did pull up procmon (nothing jumped out there as being an obvious offender). I also ran process explorer from sysinternals (I have attached the process explorer of these two application threads.) No other software we own behaves in this nature when running alongside LO. Anyone have any input on what could have changed from 4.2 through current to cause the LO suite to freeze after another application is launched?
Comment 1 Julien Nabet 2015-12-08 19:41:10 UTC
1) Did you install any LO extensions?
2) Did you install specific fonts?
3) For the test, could you rename your LO directory profile? (see https://wiki.documentfoundation.org/UserProfile#Windows)
4) Could you give a try to a more recent LO version? (5.0.3 is the last stable one)
Comment 2 mwallinger 2015-12-08 22:00:33 UTC
1) Did you install any LO extensions? 

No extensions installed. 

2) Did you install specific fonts?

No specific fonts. All default fonts used. 

3) For the test, could you rename your LO directory profile? (see https://wiki.documentfoundation.org/UserProfile#Windows)
4) Could you give a try to a more recent LO version? (5.0.3 is the last stable one)

This issue occurs on LO 4.3 through 5.0.3.2; currently running 5.0.3.2.

Extra details:

We freshly imaged up a computer with Windows 7 64bit:
-installed current patches, rebooted, and patched until installing all available security patches from M$. Rebooted again.
-Installed LO 5.0.3.2 taking all defaults
-Installed Meditech EMR software
-Tested by launching LO, then writer, then launching Meditech (issue of LO freezing occurred at this point.)
Comment 3 Julien Nabet 2015-12-08 22:49:29 UTC
(In reply to mwallinger from comment #2)
>...
> 3) For the test, could you rename your LO directory profile? (see
> https://wiki.documentfoundation.org/UserProfile#Windows)
> 4) Could you give a try to a more recent LO version? (5.0.3 is the last
> stable one)
> 
> This issue occurs on LO 4.3 through 5.0.3.2; currently running 5.0.3.2.
> 
> Extra details:
> 
> We freshly imaged up a computer with Windows 7 64bit:
> -installed current patches, rebooted, and patched until installing all
> available security patches from M$. Rebooted again.
> -Installed LO 5.0.3.2 taking all defaults
> -Installed Meditech EMR software
> -Tested by launching LO, then writer, then launching Meditech (issue of LO
> freezing occurred at this point.)

First, thank you for your feedback.
Since it's a freshly imaged up computer where you installed 5.0.3.2, you don't have any remnant from a previous version, do you? I mean, the tests with previous LO versions were before you've installed from scratch Win7.
Remark: I suppose you monitored RAM and the computer has enough RAM to run the 2 applis in the same time (+ antivirus and other softs).

Just to be sure it's not due to something specific in a file, you can reproduce the problem with a brand new empty odt (Write) file?

Could you provide precise Java version? 32, 64 bits? 1.6, 1.7, 1.8?
You must know that LO 64 bits needs Java 64 bits and LO 32 bits needs Java 32 bits.
By any chance, do you know if Meditech EMR uses Java too?

I don't know if it's easy to do because I'm more accustomed with Linux, but would it possible you retrieve a backtrace during an hang? (see https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#Windows:_How_to_get_a_backtrace)
Comment 4 mwallinger 2015-12-09 15:34:26 UTC
Created attachment 121173 [details]
backtrace log

this is the backtrace log
Comment 5 mwallinger 2015-12-09 15:35:03 UTC
Created attachment 121174 [details]
Backtrace force dump

Forced LO to crash using procdump.exe with a -h.
Comment 6 mwallinger 2015-12-09 15:40:23 UTC
(In reply to Julien Nabet from comment #3)
> (In reply to mwallinger from comment #2)
> >...
> > 3) For the test, could you rename your LO directory profile? (see
> > https://wiki.documentfoundation.org/UserProfile#Windows)
> > 4) Could you give a try to a more recent LO version? (5.0.3 is the last
> > stable one)
> > 
> > This issue occurs on LO 4.3 through 5.0.3.2; currently running 5.0.3.2.
> > 
> > Extra details:
> > 
> > We freshly imaged up a computer with Windows 7 64bit:
> > -installed current patches, rebooted, and patched until installing all
> > available security patches from M$. Rebooted again.
> > -Installed LO 5.0.3.2 taking all defaults
> > -Installed Meditech EMR software
> > -Tested by launching LO, then writer, then launching Meditech (issue of LO
> > freezing occurred at this point.)
> 
> First, thank you for your feedback.
> Since it's a freshly imaged up computer where you installed 5.0.3.2, you
> don't have any remnant from a previous version, do you? I mean, the tests
> with previous LO versions were before you've installed from scratch Win7.
> Remark: I suppose you monitored RAM and the computer has enough RAM to run
> the 2 applis in the same time (+ antivirus and other softs).
> 
> Just to be sure it's not due to something specific in a file, you can
> reproduce the problem with a brand new empty odt (Write) file?
> 
> Could you provide precise Java version? 32, 64 bits? 1.6, 1.7, 1.8?
> You must know that LO 64 bits needs Java 64 bits and LO 32 bits needs Java
> 32 bits.
> By any chance, do you know if Meditech EMR uses Java too?
> 
> I don't know if it's easy to do because I'm more accustomed with Linux, but
> would it possible you retrieve a backtrace during an hang? (see
> https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#Windows:
> _How_to_get_a_backtrace)

Thank you for your help!
No previous version was installed on the fresh OS install. The machine we are working from is has 4GB RAM installed - had no AV installed, and generally 1GB is more than enough to run LO and Meditech at the same time. 
-A brand new ODT file is used each time we are diagnosing the issue.
-The issue occurs if Java is installed or not. I have test with Java 8u65 (8.0.650.17) and 66v2 so far; same issue occurs no matter that java version. The EMR does not use Java at all to my knowledge.

Backtrace log has been attached, and I also did a force dump mentioned at the bottom of the page. 

Hope this is helpful.

-Mark
Comment 7 Julien Nabet 2015-12-10 19:21:25 UTC
Caolan: 
I noticed this part in bt:
0149f67c 64c25fdc 03c6f858 2608bf20 66ea0c68 mergedlo!WinSalGraphics::GetDevFontList+0x636
0149f6a0 64c25ffb 00000001 2608bf44 66ea0c68 mergedlo!OutputDevice::ImplRefreshFontData+0x9c
...
mergedlo!OutputDevice::ImplRefreshFontData+0xbb
0149f84c 64c26038 64c25f40 00000001 00000001 mergedlo!OutputDevice::ImplUpdateFontDataForAllFrames+0x29
0149f860 64b77cbb 00000001 2608b10c 0a02cf00 mergedlo!OutputDevice::ImplUpdateAllFontData+0x18
0149f88c 64b784c5 00000012 2608b16c 00000012 mergedlo!ImplHandleSalSettings+0xab
0149f8ec 64e5bbc7 00ef8a68 09eaaa38 00000012 mergedlo!ImplWindowFrameProc+0x3d5
0149f91c 64e5e41a 00070304 0000001d 00000000 mergedlo!ImplHandleSettingsChangeMsg+0x107
0149f964 64e5edc0 00070304 0000001d 00000000 mergedlo!SalFrameWndProc+0x38a
0149f9b0 75fac4e7 00070304 0000001d 00000000 mergedlo!SalFrameWndProcW+0x60

There a lot of calls to ImplRefreshFontData (12 times!)
But I don't know why it's triggered only when opening the other soft

thought you might be interested since it concerns vcl part.

Putting at NEW meanwhile since there's a bt.
Comment 8 mwallinger 2015-12-14 21:00:53 UTC
Small update... Tested with the latest AOO (4.1.2) no issues opening a new document with Writer and running Meditech at the same time. The hanging issues does not present with AOO taking all defaults on installation.Not sure if this is helpful, but wanted to pass on the information.
Comment 9 mwallinger 2015-12-23 19:12:24 UTC
Any update on this issue? 

I haven't seen any updates here recently, and want to confirm there is nothing I need to be doing to allow this issue to be resolved in a timely manner.
Comment 10 Julien Nabet 2015-12-23 20:57:40 UTC
(In reply to mwallinger from comment #9)
> Any update on this issue? 
> 
> I haven't seen any updates here recently, and want to confirm there is
> nothing I need to be doing to allow this issue to be resolved in a timely
> manner.

Mwallinger: there are lots of bugs and it depends on devs.
in fact, I think you've got 3 choices:
- you can try yourself to make a patch to fix this
- you can pay someone to fix it
- just wait someone fix it

(just my opinion of course :-))
Comment 11 QA Administrators 2017-01-03 19:57:49 UTC Comment hidden (obsolete)
Comment 12 mwallinger 2017-01-04 14:20:04 UTC
The bug is still present. The version is 5.2.3 that we see the issue. The OS we are seeing the issue on is Windows 7 32 and 64 bit.
Comment 13 QA Administrators 2018-01-05 03:40:25 UTC Comment hidden (obsolete)
Comment 14 mwallinger 2018-01-08 19:03:34 UTC
I have completed the requested actions you mentioned, plus tried the new 6.0 prerelease.

The old 3.3 release does not have any issues with going to a not responding state after launching the Meditech application.

The prelease 6.0 Libre Office has the same issue as mentioned in the other bugs... Working from Libre office is normal up until launching the Meditech application, then going back to Libre Office shows Libre to not be responding.

I have added the regression keyword.
Comment 15 Julien Nabet 2018-01-08 20:08:53 UTC
Mike: noticing your work about optimizing fonts loading (eg: https://gerrit.libreoffice.org/#/c/47112/), thought you might be interested in this one.
Last attachment shows this:
0149f67c 64c25fdc 03c6f858 2608bf20 66ea0c68 mergedlo!WinSalGraphics::GetDevFontList+0x636
0149f6a0 64c25ffb 00000001 2608bf44 66ea0c68 mergedlo!OutputDevice::ImplRefreshFontData+0x9c
Comment 16 Buovjaga 2019-01-14 19:23:00 UTC
(In reply to Julien Nabet from comment #15)
> Mike: noticing your work about optimizing fonts loading (eg:
> https://gerrit.libreoffice.org/#/c/47112/), thought you might be interested
> in this one.
> Last attachment shows this:
> 0149f67c 64c25fdc 03c6f858 2608bf20 66ea0c68
> mergedlo!WinSalGraphics::GetDevFontList+0x636
> 0149f6a0 64c25ffb 00000001 2608bf44 66ea0c68
> mergedlo!OutputDevice::ImplRefreshFontData+0x9c

The patch is now merged.

mwallinger: might be interesting, if you tried with a master build that has the font loading fix: https://dev-builds.libreoffice.org/daily/master/Win-x86_64@42/current/
Comment 17 mwallinger 2019-01-15 16:03:13 UTC
Just installed the 6.3 alpha client without any errors. LO still hangs after launching the Meditech software.
Comment 18 Julien Nabet 2019-01-15 16:12:08 UTC
(In reply to mwallinger from comment #17)
> Just installed the 6.3 alpha client without any errors. LO still hangs after
> launching the Meditech software.

Would it be possible you attach a backtrace/backtrace force dump with this version?
Perhaps we'll see more clearly where's the pb since the font one is fixed now.
Comment 19 Buovjaga 2019-01-15 16:50:31 UTC
(In reply to Julien Nabet from comment #18)
> Would it be possible you attach a backtrace/backtrace force dump with this
> version?
> Perhaps we'll see more clearly where's the pb since the font one is fixed
> now.

For the backtrace, the best version is this: https://dev-builds.libreoffice.org/daily/master/Win-x86@39/current/ because it comes with debug support.
Comment 20 Buovjaga 2019-04-14 13:13:57 UTC
mwallinger: there is a new bibisect repository for 4.3 on Windows. You might try to find out the offending code change with it.

General instructions for Win: https://wiki.documentfoundation.org/QA/Bibisect/Windows

The command to use (in cygwin) to clone the repository:
git clone https://git.libreoffice.org/bibisect-win32-4.3

Important note:

Please also fetch commit notes:

git fetch origin refs/notes/commits:refs/notes/commits

Do regular bibisect with tag oldest and latest, and if you end up on a commit that has a note attached, please do as it says (continue between the tags fixup_oldest and fixup_latest)

I have had good results with this repository.