In Windows, log off with a LibreOffice instance running (with a file or at least an empty document open). After logging back in, start LO again. => LO opens with recovery dialog, meaning it didn't exit properly. Alternatively, before starting LO look in the user profile directory, and note the lock file (named ".lock") there, implying the same. While it's true Windows forcibly shuts down applications refusing to exit after a while when ending a user session, LO closes right away, but not cleanly. We should make an attempt at shutting down properly. Observed using LO 5.4.0.1 / Windows 7. Likely relevant: https://msdn.microsoft.com/en-us/library/windows/desktop/aa376890(v=vs.85).aspx http://opengrok.libreoffice.org/xref/core/vcl/win/window/salframe.cxx#5705
Note: don't make any changes to the document during repro, in that case there is a save dialog and LO exits fine after making a choice, but if it's an empty/unchanged document, the shutdown process is not proper.
Hmm, maybe related to bug 108299 with zombie soffice.bin/.exe when OpenGL enabled? Does it behave without OpenGL?
Patch in gerrit: https://gerrit.libreoffice.org/#/c/39884/
Stuart, it's not OpenGL related, happens with default rendering as well. I need to correct my comment 1, it happens if there's a save dialog as well, but in both cases not all the time. However, most of the time LO doesn't exit cleanly. Collecing the relevant details on Windows messages/behavior here: https://blogs.msdn.microsoft.com/oldnewthing/20080421-00/?p=22663 https://msdn.microsoft.com/en-us/library/windows/desktop/aa376890 https://msdn.microsoft.com/en-us/library/windows/desktop/aa376889
Proposed sketch of solution: 1. Add a handler of WM_ENDSESSION to soffice.bin. Don't handle WM_ENDSESSION there - so by default, this process will simply allow termination. 2. Set its process shutdown level to some high value (0x3FF) to receive this message first (see SetProcessShutdownParameters: https://msdn.microsoft.com/en-us/library/ms686227). 3. Set soffice.bin's process shutdown level to a low value (e.g. to 0x100) to ensure that it doesn't get the notification before soffice.exe finished handling its own WM_ENDSESSION. 4. Handle WM_QUERYENDSESSION in soffice.bin, so that if user has unsaved work, a save query is shown, and if user decided to cancel, then WM_QUERYENDSESSION returns FALSE -> shutdown is terminated. If WM_QUERYENDSESSION returns true, then soffice.bin continues shutdown here, not waiting any other messages. 5. When soffice.exe receives WM_ENDSESSION with wParam = 1, it means that all programs accepted the shutdown in WM_QUERYENDSESSION (including soffice.bin), so we know that soffice.bin is already terminating, and haven't yet received its WM_ENDSESSION (because of shutdown level) -> just wait in the WM_ENDSESSION handler until soffice.bin is finished, and then return. Possibly send an additional shutdown signal to soffice.bin to make sure. I hope this sequence could help resolving this issue.
Correction to #1 in comment 5: Don't handle WM_ENDSESSION there -> Don't handle WM_QUERYENDSESSION there
And another correction to the same #1: it tells about soffice.exe, not about soffice.bin. Sorry for noise.
See also: http://nabble.documentfoundation.org/tdf-109085-status-tc4220674.html
Dear Mike Kaganski, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assigned it back to yourself if you're still working on this.
*** Bug 117952 has been marked as a duplicate of this bug. ***
I saw Oliver Brinzing's comment in bug 118573 comment 21 on how to simulate shutdown: rmlogotest.exe (C:\Program Files (x86)\Windows Kits\10\App Certification Kit) https://superuser.com/questions/959364/on-windows-how-can-i-gracefully-ask-a-running-program-to-terminate#1154058 - start "quickstart.exe" - get "soffice.bin" PID form taskmanager - rmlogotest.exe <pid> - crash ------ As far as I can see, in Windows 7 using the following command has the same effect: taskkill /f /pid <pid>
(In reply to Aron Budea from comment #11) > As far as I can see, in Windows 7 using the following command has the same > effect: > taskkill /f /pid <pid> I'm uncertain whether this is really useful here, whether it's the same procedure as logging off, or whether it simply kills the process... could be the latter.
https://gerrit.libreoffice.org/62881
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/3d8c159841bcab7365b2bed3df71ed3c15188312%5E%21 tdf#109085: don't assume MtaOleReq window is still valid at shutdown It will be available in 6.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
A polite ping to Mike Kaganski: Is this bug fixed? if so, could you please close it as RESOLVED FIXED ? Otherwise, Could you please explain what's missing? Thanks
(In reply to Xisco Faulí from comment #15) > Is this bug fixed? if so, could you please close it as RESOLVED FIXED ? > Otherwise, Could you please explain what's missing? The original issue still persists (tested with a build from yesterday, 18-12-13). It's not obvious what needs to be fixed for this to work, so unless the issue is gone after a similar fix, or there is a new discovery, we don't know what's still missing.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/11a2809e369b2a6fcbb2d7f0db131a945557c6e2%5E%21 tdf#122435: reimplement fix for tdf#109085 It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-6-2": https://git.libreoffice.org/core/+/9d7baded9f315096f247af15a23fd899fc4facc3%5E%21 tdf#122435: reimplement fix for tdf#109085 It will be available in 6.2.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
@Aron Budea, is this issue still reproducible after Mike's patches ?
Yes, tested again with LO 6.3.0.0.alpha0+ (x64) (4f810905fa74128871f2fe924a3d28a79f4e4261) / Windows 7. I had to repeat it 3-4 times, but got a .lock file remaining, indicating LO didn't shut down cleanly.
Dear Aron Budea, 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