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?
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)
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.)
(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)
Created attachment 121173 [details] backtrace log this is the backtrace log
Created attachment 121174 [details] Backtrace force dump Forced LO to crash using procdump.exe with a -h.
(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
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.
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.
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.
(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 :-))
** 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 on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170103
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.
** 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
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.
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
(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/
Just installed the 6.3 alpha client without any errors. LO still hangs after launching the Meditech software.
(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.
(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.
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.
Dear mwallinger, 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://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
I turn this to NeedInfo for reporter to test again with LO master from https://dev-builds.libreoffice.org/daily/master/current.html. That seems to be commercial software, that LO testers and devs are unlikely to have, so more info is needed.
Dear mwallinger, 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
Dear mwallinger, 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-FollowUp