Install LO Dev 24.8 on MS Windows, in addition to some LO Stable version. They are of course installed in parallel, in their own directories, and never executed simultaneously. A few days ago I noticed that _each_ run of LibreOfficeDev leaves a process opened in the background, seen listed in Windows' Task Manager, after I have closed the program normally. In the installation procedure, I never select to automatically start LO with the OS. Every run is executed manually. No repro when installing LibreOfficeDev_24.8.0.0.alpha0_Win_x86-64.msi built as of 2024-04-30 – I re-installed that version, tested it, and then again installing the msi built on 2024-05-11 – so this started at some point after build date 2024-04-30. Downloaded from TB77 (not from TB78). We are approaching alpha1 status of LO 24.8, so this should rather have a higher-than-normal priority, IMHO.
I can not confirm. But I perform simplest /a administrative msiexec.exe from command line with a TARGETDIR= parameter, then modify the program/bootstrap.ini to use an $ORIGIN/.. value. When launched, just one soffice.bin process is present in Task Manager. Close/shutdown removes that process. Quicklaunch is not enabled, and I don't configure any additional .OXT extensions. @Ady, anything different with your install STR? =-testing-= TB77 nightly 20240510 Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 0ffdfb58a07e2a1b89a36bc241c6a2767e82cd2c CPU threads: 8; OS: Windows 10 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
(In reply to V Stuart Foote from comment #1) > @Ady, anything different with your install STR? I don't run by command line. I install each new Dev update version in the same specific directory (so one new Dev installation replaces the older one). I selected this directory the first time, and every Dev msi always selects this same directory by default. Since I have several languages and dictionaries installed with the Dev version, I always select the personalized option when installing (instead of the "typical" radius option). I never select to use QuickLaunch. I also select to add a direct access link to the desktop (so I have one for the Dev version and another for the Stable version). I have a Stable version (soffice.exe located in C:\Program Files\LibreOffice\program, 7.6.5 ATM), a Dev version (in D:\LO\ALPHA\program, note the separate "D:"), and several "Windows portable" versions (installed from paf.exe installers), each installed in separated directories. In order to run each soffice.exe, I have created "direct access" links to each "parallel" installation. The whole set of direct links are all located in one "central" directory, and I double-click on the icon that I want to run according to LO version. Similarly, I have AOO (and some other spreadsheet tool). I am usually "clean" (ordered) regarding which version I am running, and I always wait until one version is completely closed before executing a different version. When I have not waited enough time, I get a message that another version is still closing, so I cannot have more than one soffice.exe version running simultaneously. A few days ago, I received such message a couple of times when trying to launch some portable version(s), and so I found the left-overs in Windows Task Manager. I can replicate the issue, also after rebooting. After killing every LibreOfficeDev (and related Calc process, if there is such) line in Windows' Task Manager, I can replicate the same behavior again. Open LO Dev Start Center and then close it; there is one additional left-over. Each run leaves a new left-over. I can run the Stable version, but any of the "portable" versions (starting with 4.0) is blocked with the aforementioned message, unless I kill the left-overs. By chance I have saved the LO Dev msi installer built on 2024-04-30, so after some few days of this new issue, I reinstalled it over the same "D:\LO\ALPHA\" location. No problem, no repro. I then reinstalled the LO Dev msi installer built on 2024-05-11 (the latest ATM), and I can repro the problem again, just as it has been for a couple/few days now. If it happens to be of any relevance, my Windows OS is not in English, and the msi installer runs in the same language as my OS, but the default language for LO in all my installations is English (USA) (by choice), with several additional UI languages and dictionaries installed too. IDK which other details might be needed.
Alright, your install method is quite different than what is suggested. Performing an MS Installer "Administrative" aka. "server" install, done with the /a flag simply extracts content of the installer msi. And technically it does not install the package. Each package so extracted stands alone, and can/should be configured to not use your user profile. With this /a install and config, there should not be a "LibreOfficeDev" folder entry in your %APPDATA% (C:\Users\<username>\AppData\Roaming) folder. Only if you run the installer as for a default /i flag will you get an install, which by default will write to C:/Program Files/LibreOfficeDev. And to fully integrate with Win os/DE you'd have to add a "WRITER_REGISTRY=1" flag to the install (as msi package for the dev builds have that disabled and set 0). Doing the /a installs are simpler to cleanup, use TARGETDIR=<fullPathToInstall>, and adjust the bootstrap.ini Userinstallation= stanza to use $ORIGIN rather than $SYSUSERCONFIG. Then simply deleting the folder will remove all trace. Otherwise, you need to clean the registry--and config of each of the dev builds will interfere with all others. Though fortunately with defaults--the dev builds should not touch the release build configs. If you want to install/test like that, what I'd suggest is to clear the per user profile that links to you D:\LO\Alpha\program used in your custom installs. Even though install is to your D: drive, your user profile is going to be C:\Users\<yourusername>\AppData\Roaming\LibreOfficeDev. Delete it to clear the profile (on next launch that will recreate with defaults. See if that clears the zombie soffice.bin at close of the recent build.
(In reply to V Stuart Foote from comment #3) > If you want to install/test like that, what I'd suggest is to clear the per > user profile that links to you D:\LO\Alpha\program used in your custom > installs. Even though install is to your D: drive, your user profile is > going to be C:\Users\<yourusername>\AppData\Roaming\LibreOfficeDev. Delete > it to clear the profile (on next launch that will recreate with defaults. I have "reset" my LO Dev profile, but I have not manually deleted anything in C:\Users\<yourusername>\AppData\Roaming\LibreOfficeDev. I'd like to ask you, what should I manually delete, specifically, and what not? Additionally, should I delete anything using regedit.exe? FWIW, I have been installing and using LO Dev as I described, for more than a year, with several updates per month. The left-overs processes in Windows' Task Manager are new, and I cannot replicate the problem when going back to the build from 2024-04-30. So maybe the "/a" installation method overcomes or avoids the problem, whereas the "common" installation method allows the problem to be triggered. If this happens to be true, then at some point the "common" install method will arrive to the Stable branch (e.g. when 24.8 becomes Stable Fresh), and then users will report the same problem. My point is that perhaps the "common" installation should be tested now with LO Dev 24.8 in order to test whether the left-overs of soffice.exe can be replicated, after launching and closing the LO Dev Start Center several times.
I can not reproduce with Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 2b85bceca88ab119fff5cbdc41fe913435a479ca CPU threads: 16; OS: Windows 11 (10.0 build 22631); UI render: default; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
So went ahead and did an actual /i install of the TB77 nightly from 20240510. Custom to a named folder (C:\Program Files\LibreOfficeDev_24"), just the en-US dict and locale, no default document association, no quickstarter. Sorry, but still can't repro the zombie soffice.bin instance, opening and closing to Start Center. I get just one soffice.exe/soffice.bin pair, and both close cleanly on exit. I was curious about the MSI packaging. And should have logged the install (done via command line rather than GUI and adding a /L*v instLog.txt). Despite being an alpha+, not yet beta, I do see significant writes into Windows registry. But if I open the MSI in Orca, and the 'Property' table's -> WRITE_REGISTRY value is set to 0, and checked the Win registry for items that tested for that control. Did not see any, and no recent change to the Windows build solver: solenv/bin/modules/installer/windows/registry.pm To clean up between installs, you should be able to use the Win appwiz.cpl to remove the LODev cleanly, then use the Find command in regedit.exe to check for any left overs (look for "LibreOfficeDev"). Or for a more robust uninstall with a bit more aggressive registry cleanup, VSRevo Revo Uninstaller is my preferred tool. =-testing-= Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 0ffdfb58a07e2a1b89a36bc241c6a2767e82cd2c CPU threads: 8; OS: Windows 10 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
I uninstalled LO Dev, manually searched for LibreOfficeDev in the registry and deleted every item I found (except those also related to the antivirus, because the antivirus itself does not allow me to perform such action). Between each step I also reboot the system. I did not use Revo. While re-installing LO Dev 2024-05-11, the original custom location (D:\LO\ALPHA\) was not recognized by default as it used to happen before. Instead, the default location (under program files) was offered as installation location. This was expected. I modified the installation location to be the same customized location as before. When I selected to personalized installation (not the "typical" radius option), the same custom options that I used before (with additional languages and dictionaries) were already selected. This was not expected, and it hints that some remnants were left-over from the normal uninstall procedure. For the purpose of this ticket, I am OK with this, but others might disagree. Launching the new soffice.exe adds 1 process to the Windows' Task Manager. Closing the Start Center leaves that first process and adds 1 more, leaving 2 left-over processes in the background. New processes are left over for every such launch-and-close steps. Once again I installed LO Dev built on an older date as before. Once again I do not have any left-overs. So, for now I will have to remain at this LO Dev date. Hopefully someone will be able to replicate the behavior and gather more info, or alternatively I might find where the problem is in this system.
(In reply to V Stuart Foote from comment #6) > Despite being an alpha+, not yet beta, I do see significant writes into > Windows registry. Note that writing to registry in this case is likely related to the Windows Installer service operation itself (e.g., its uninstall logging), not to the registry settings that LibreOffice MSI has in it (registration of explorer extensions, file type associations, and so on). ady, can you please: 1. Check which command line is reported in Windows Task Manager for the leftover process? You might need to enable "Command line" column in Details tab for that. The command line may be long. 2. Use https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg#Producing_a_mini_dump to produce a minidump of the leftover BIN process.
See also: https://ask.libreoffice.org/t/exit-lo-windows/93863
(In reply to Mike Kaganski from comment #8) > ady, can you please: > > 1. Check which command line is reported in Windows Task Manager for the > leftover process? You might need to enable "Command line" column in Details > tab for that. The command line may be long. LibreOfficeDev_24.8.0.0.alpha0_Win_x86-64.msi built 2024-05-13 downloaded from TB77. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 0dcaff6043e1f24ce0fa354dff80a86e40622247 CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: es-AR (es_AR); UI: es-ES Calc: CL threaded When first launching LO Dev, Task Manager shows 1 _background_ Process line (I find the background detail unexpected; for soffice.exe) and 1 active Process line (for soffice.bin). Command lines in TM are as follows: * soffice.exe: "D:\LO\ALPHA\program\soffice.exe" * soffice.bin: "D:\LO\ALPHA\program\soffice.exe" "-env:OOO_CWD=2D:\\D\\ALPHA\\program" If I also open some ods file, a sub-process is listed under the active LibreOfficeDev line (corresponding to soffice.bin); no command line listed for this sub-process. Closing the ods file (so only the Start Center is left open), the sub-process is still listed in the same place, under the active LibreOfficeDev process. Once I close the Start Center, the sub-process is not there anymore (or I don't see it anywhere), and both LibreOfficeDev processes are shown under the background Processes. The command lines are the same as before. In Task Manager, soffice.exe is left with 0.5MB of RAM in use, and soffice.bin is left using 93.6MB of RAM, according to Task Manager; the specific amount changes according to how many times I launched LO Dev. If I use menu Help > Restart in Safe Mode, LO Dev does not automatically restarts. If I run soffice.exe again, the expected wizard for Safe Mode is launched. Once I reset to defaults in the wizard, the restart automatically launches the normal Start Center. Once closing all, I am left with multiple background processes (a pair for every launch). > > 2. Use > https://wiki.documentfoundation.org/ > How_to_get_a_backtrace_with_WinDbg#Producing_a_mini_dump to produce a > minidump of the leftover BIN process. Is this the same as saving a dump from Task Manager? After closing LO Dev, the dump for soffice.bin from TM is near 600MB. If I still need to create a new dump as described in that wiki page, I would like to know, which executable file should I use: procdump.exe, procdump64.exe, or procdump64a.exe? In addition, do I need to install WinDbg and follow the whole set of instructions? I have some limitations to what I can do in this system, so I might not be able to complete the instructions. Hopefully the info I already provided is enough for someone more capable to replicate the problem (which does not happen with LO Dev from just a few days ago, and does not happen when reinstalling that same build over the new one).
Created attachment 194107 [details] WinDbg analyze -v on soffice.bin dump from task manager (In reply to Mike Kaganski from comment #8) > ady, can you please: > > 1. Check which command line is reported in Windows Task Manager for the > leftover process? You might need to enable "Command line" column in Details > tab for that. The command line may be long. * soffice.exe: "D:\LO\ALPHA\program\soffice.exe" * soffice.bin: "D:\LO\ALPHA\program\soffice.exe" "-env:OOO_CWD=2D:\\D\\ALPHA\\program" > > 2. Use > https://wiki.documentfoundation.org/ > How_to_get_a_backtrace_with_WinDbg#Producing_a_mini_dump to produce a > minidump of the leftover BIN process. When following the instructions in that wiki section/page, I am not able to trigger a crash as requested, because there was never such crash; LO Dev just remains in the background after being closed. From the Task Manager, I saved a dump file from soffice.bin. I am attaching the "analyze -v" result as requested in that wiki page. I have no idea whether it can be useful.
I have downloaded from TB77 several daily msi for 24.8 alpha built on several dates in order to test when exactly the problem started. Using LibreOfficeDev_24.8.0.0.alpha0_Win_x86-64.msi up to 2024-05-06 included, all works as expected. Since the installer dated 2024-05-08, when I launch and close the Start Center, I see the left-overs in Task Manager. Using prior installers, all works correctly. I don't know what changed on that date (or rather, after 2024-05-06 and before 2024-05-08), but something did. I guess that the problem might not be related to the installer, but to soffice.bin or to soffice.exe, or something in how they are built(?). That's far from my knowledge, as I am not a developer. I hope the current administrator/owner of TB77 can save these daily installers (at least 2024-05-06 and 2024-05-08), in order for other users to be able to download them and attempt to replicate the problem (seen on the latter date).
I have performed a lot of tests, with different dates, uninstalled everything (including the stable version) with Revo, including "/a" installation on a separate directory and following the related instructions about "bootstrap.ini" and what not. I also tested with TB78 pollux-wix (which also started around these dates, approx.) The problem always starts on 2024-05-08. Until 2024-05-06 (included), no problem. IDK how to gather relevant info when actually running and closing soffice. Either some build dependency changed after 2024-05-06 and before 2024-05-08, or some commit between those dates is not allowing the processes to close in my system. Possible relevant info (see dates): * <https://wiki.documentfoundation.org/WikiAction/history/Development/External_Libraries> * Build ID dated 2024-05-06: 7a895ec4205659038aa95941b65715fed1a3e7be * Build ID dated 2024-05-08: 92815f3a464b447898ecf52492247335228e4a72 (so you can take a look at the history/log/diff) Additionally, would someone please test when installing a recent 24.8 alpha daily to an uncommon path, instead of using %PROGRAMFILES% "c:\Program files"?
Not repro with Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 1b45ca1aa7d7cb8e7adcc07f8c60e26a413eca8c CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded I have it installed in a different path than C:Program Files, with several other versions. After running four different versions at the same time, and closing the latest 24.8.0.0.alpha1+, all soffice.* closes.
(In reply to m_a_riosv from comment #14) > I have it installed in a different path than C:Program Files, with several > other versions. > > After running four different versions at the same time, and closing the > latest 24.8.0.0.alpha1+, all soffice.* closes. Thank you. I have uninstalled LO and LO Dev several times already, trying to avoid the problem (with any date after 2024-05-06, the last one that works for me). I guess I cannot keep testing/using LO Dev anymore :(.
I use https://dev-builds.libreoffice.org/si-gui/setup.exe to install parallel versions, you can easily choose where to install, it also allows you to select the version to download. There is also a Java version in the same folder, which works also on other operating systems besides Windows.
(In reply to m_a_riosv from comment #16) > I use https://dev-builds.libreoffice.org/si-gui/setup.exe to install > parallel versions, you can easily choose where to install, it also allows > you to select the version to download. > > There is also a Java version in the same folder, which works also on other > operating systems besides Windows. Thank you. I considered it at one point in the past. Since I am already performing my tests with msiexec "/a" as Stuart suggested (together with additional arguments), and considering other current factors related to SI-GUI, the result will be the same as I have already experienced. Important note (JIC): When LO Dev is still running, the processes in Task Manager are listed under the "Applications" Group (if TM is set to display the list with the "Group by type" view). Once I completely close LO Dev, the left-over processes are seen under the _background_ processes Group. The original processes/lines/rows under the aforementioned "Applications" Group are no longer present when LO Dev is closed. That means that the left-over processes (if there are such) are seen under the second Group in the list, not in the same place as the original "Applications" Group. Whoever attempts to reproduce the problem, please be sure that you are searching/looking for the left-over processes where they are supposed to be listed, not in the typical "Applications" Group in the Task Manager list.
> * Build ID dated 2024-05-06: 7a895ec4205659038aa95941b65715fed1a3e7be > > * Build ID dated 2024-05-08: 92815f3a464b447898ecf52492247335228e4a72 > > (so you can take a look at the history/log/diff) Up until 2024-05-06: <https://git.libreoffice.org/core/+/7a895ec4205659038aa95941b65715fed1a3e7be> there is no problem. The problem started after the above and before the following: <https://git.libreoffice.org/core/+/92815f3a464b447898ecf52492247335228e4a72> dated 2024-05-08. Reviewing the diff/log between those 2 commits (including them too), could someone please find whether there is something related to the following errors? warn:desktop.app:10004:12976:unotools/source/ucbhelper/localfilehelper.cxx:86: error removing directory file:///D:/LO/ALPHA/program/../program/../user/extensions warn:vcl.gdi.wndproc:10004:12976:vcl/win/app/salinst.cxx:619: ignoring timer event because we are shutting down warn:vcl.gdi.wndproc:10004:12976:vcl/win/app/salinst.cxx:619: ignoring timer event because we are shutting down warn:vcl.gdi.wndproc:10004:12976:vcl/win/app/salinst.cxx:619: ignoring timer event because we are shutting down warn:vcl.gdi.wndproc:10004:12976:vcl/win/app/salinst.cxx:619: ignoring timer event because we are shutting down warn:vcl.gdi.wndproc:10004:12976:vcl/win/app/salinst.cxx:619: ignoring timer event because we are shutting down warn:vcl.gdi.wndproc:10004:12976:vcl/win/app/salinst.cxx:619: ignoring timer event because we are shutting down Entity: line 1: parser error : Document is empty ^ warn:vcl.gdi.wndproc:4292:4324:vcl/win/app/salinst.cxx:619: ignoring timer event because we are shutting down warn:vcl.gdi.wndproc:4292:4324:vcl/win/app/salinst.cxx:619: ignoring timer event because we are shutting down warn:vcl.gdi.wndproc:4292:4324:vcl/win/app/salinst.cxx:619: ignoring timer event because we are shutting down warn:vcl.gdi.wndproc:4292:4324:vcl/win/app/salinst.cxx:619: ignoring timer event because we are shutting down There might also be some other errors, but I am having difficulties logging them (so the following are partial quotes): warn:desktop.app:14024:14280:desktop/source/app/app.cxx:260: cannot create path warn:desktop.app:14024:14280:desktop/source/app/app.cxx:1328: userinstall failed 4 warn:configmgr:14024:2564:configmgr/source/components.cxx:190 error writing modifications com.sun.star.uno. /jenkins/daily_workspace/tb/src_master/configmgr/source/writemodfile.cxx:578 I also find curious that there are 3 slash bars after "file", as in "file:///", instead of just 2 slash characters. Hopefully these might help/hint where to look for the possible problem.
I can reproduce with Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: e3bd3c7e3178dc091fd002628f052666b4db3be6 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded But running LO again the first instance disappear.
(In reply to m_a_riosv from comment #19) > But running LO again the first instance disappear. Please try the following: 1. Launch LO Dev Start Center and then a new empty Calc. 2. Close all items related to LO (Calc and Start Center). 3. Repeat steps 1 and 2 again. 4. Open Windows' Task Manager and look for the _background_ processes. In the list in my TM, the first group is for active applications, the second group is for background processes, and the third group is for Windows' processes. Within each group, I have the list sorted alphabetically by Name (of the process). Additionally, the column for the Name of the Command is also displayed – which is not shown by default, you have to add it manually. 5. Click once on any process of the TM's list. 6. Press the letter "L" on your keyboard. For each time you press it, the next process in the list that starts with that letter will take focus. 7. If you still don't see any background process left-over for Lo Dev, please review the background processes group to see whether there is any row/line hidden within another process. For example, if you launched LO Dev from a command line, there might be some main process, whether in the active applications group or in the background processes group, that has LO Dev as a sub-process. Another example: when I launch LO Dev Start Center, and before closing it, the active applications group in Windows' Task Manager shows one LO Dev process (for soffice.bin), and within it there is another sub-process (for soffice.exe); if I open Calc, I will see instead a sub-process for it. As soon as I close all LO Dev programs (just normally, without forcing anything), I can see that the TM open applications processes group no longer lists the LO Dev processes, but there are left-overs down the list, within the background processes group. If I _directly_ launch scalc.exe (not from the Start Center, while Start Center is closed) and then close Calc (and also close Start Center, which was open with Calc), there are background left-overs for it too, listed as "LibreOfficeDev Calc". There is never a crash. I open and close the programs normally. No other versions running simultaneously. It all looks the same as usual, except for the left-overs in TM after closing LO Dev (seemingly normally).
The problem is reproduced every time with OpenCL ON. There was no problem up until build dated 2024-05-06. Menu Tools > Options > LibreOfficeDev > OpenCL > Allow use of OpenCL > set to OFF. Then, after closing LO Dev, there are no left-over processes anymore. I have tested with this setting ON and OFF 3 times. OpenCL ON > left-overs OpenCL OFF > everything is fine. Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 028ac95c0e9991b59a835527b6fed2f8d3e2bddf CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: en-US (es_AR); UI: en-US Calc: threaded
(In reply to ady from comment #21) > The problem is reproduced every time with OpenCL ON. There was no problem up > until build dated 2024-05-06. > > Menu Tools > Options > LibreOfficeDev > OpenCL > Allow use of OpenCL > set > to OFF. Then, after closing LO Dev, there are no left-over processes anymore. > > I have tested with this setting ON and OFF 3 times. > > OpenCL ON > left-overs > > OpenCL OFF > everything is fine. > > Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community > Build ID: 028ac95c0e9991b59a835527b6fed2f8d3e2bddf > CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: > Skia/Raster; VCL: win > Locale: en-US (es_AR); UI: en-US > Calc: threaded Noel: ady noticed your 7d1242b01d3ad9be1cfcf2bd3fbee9ce63dddddf move opencl check at startup inside its own thread Nobody bisected this yet, but it sounds plausible to have an effect on this.
In LO Dev (2024.05.08+), when OpenCL is ON, another symptom is that: menu Help > Restart in Safe Mode will not automatically restart LO Dev (whether in Safe Mode or otherwise); I have to restart it manually.
(In reply to ady from comment #23) > In LO Dev (2024.05.08+), when OpenCL is ON, another symptom is that: > menu Help > Restart in Safe Mode > will not automatically restart LO Dev (whether in Safe Mode or otherwise); I > have to restart it manually. The problem happens with binaries (2024.05.08+) from Tinderbox 77 or from TB 78; LO Dev Win-x86_64. The specific installation method is not a factor; it will happen anyway. There is no problem with binaries from TB 39, LO Dev Win-x86 (installed on MS Windows 64 bits). STR: 1. In LO Dev (2024.05.08+), menu Tools > Options > LibreOfficeDev > OpenCL > Allow use of OpenCL, (already) set to ON. 2. With OpenCL ON, menu Help > Restart in Safe Mode; accept restart. LO Dev should automatically re-start, but it won't. There will be LO Dev left-over (sub)processes in the background, seen in Windows' Task Manager. As long as OpenCL is ON, manually launching LO Dev and closing it again > will leave additional left-over processes. If OpenCL if OFF, there is no problem.
OK, so since this seems to be an OpenCL related issue would expect we need some sense of the affected architecture(s). On Win10 with nVidia GeForce drivers, I do not reproduce. The soffice.bin and wrapper .exe shutdown cleanly on exiting. Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: ae798781ef4df7a1fdef13af0bc459bf4f6e7b4c CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Here is my OpenCL log (opencl_devices.log) from user profile: Device Index: 0 Selected: true Device Name: NVIDIA GeForce GTX 750 Ti Device Vendor: NVIDIA Corporation Device Version: OpenCL 3.0 CUDA Driver Version: 552.12 Device Type: gpu Device Extensions: cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_fp64 cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_icd cl_khr_gl_sharing cl_nv_compiler_options cl_nv_device_attribute_query cl_nv_pragma_unroll cl_nv_d3d10_sharing cl_khr_d3d10_sharing cl_nv_d3d11_sharing cl_nv_copy_opts cl_nv_create_buffer cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_device_uuid cl_khr_pci_bus_info cl_khr_external_semaphore cl_khr_external_memory cl_khr_external_semaphore_win32 cl_khr_external_memory_win32 Device OpenCL C Version: OpenCL C 1.2 Device Available: true Device Compiler Available: true Device Linker Available: true Platform Name: NVIDIA CUDA Platform Vendor: NVIDIA Corporation Platform Version: OpenCL 3.0 CUDA 12.4.131 Platform Profile: FULL_PROFILE Platform Extensions: cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_fp64 cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_icd cl_khr_gl_sharing cl_nv_compiler_options cl_nv_device_attribute_query cl_nv_pragma_unroll cl_nv_d3d10_sharing cl_khr_d3d10_sharing cl_nv_d3d11_sharing cl_nv_copy_opts cl_nv_create_buffer cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_device_uuid cl_khr_pci_bus_info cl_khr_external_semaphore cl_khr_external_memory cl_khr_external_semaphore_win32 cl_khr_external_memory_win32
(In reply to V Stuart Foote from comment #25) > Here is my OpenCL log (opencl_devices.log) from user profile: Do you need for me to gather some info by following specific steps? Would the opencl log be the same when having OpenCL ON and OFF? Or, instead, would the log be different according to the setting? Considering the starting date of the problems, is there anything suspicious in the following commit that could trigger the kind of issues I am seeing? 7d1242b01d3ad9be1cfcf2bd3fbee9ce63dddddf "move opencl check at startup inside its own thread"
If your CPU/GPU supports OpenCL LibreOffice will build a log file of what it detects--named "opencl_devices.log" found in your LO user profile (either %APPDATA%\LibreOffice\4\cache or where you configured your user profile, e.g. $ORIGIN\..\Data\settings in the bootstrap.ini). Don't know what the log might look like without OpenCL being detected/tested fully, or if os/DE reports it unavailable. For now just post what you've got...
With OpenCL set to ON in LO Dev: Device Index: 0 Selected: false Device Name: Intel(R) UHD Graphics 620 Device Vendor: Intel(R) Corporation Device Version: OpenCL 2.1 NEO Driver Version: 23.20.16.4958 Device Type: gpu Device Extensions: cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_fp16 cl_khr_depth_images cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_icd cl_khr_image2d_from_buffer cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_intel_subgroups cl_intel_required_subgroup_size cl_intel_subgroups_short cl_khr_spir cl_intel_accelerator cl_intel_media_block_io cl_intel_driver_diagnostics cl_intel_device_side_avc_motion_estimation cl_khr_priority_hints cl_khr_subgroups cl_khr_il_program cl_khr_fp64 cl_intel_planar_yuv cl_intel_packed_yuv cl_intel_motion_estimation cl_intel_advanced_motion_estimation cl_khr_gl_sharing cl_khr_gl_depth_images cl_khr_gl_event cl_khr_gl_msaa_sharing cl_intel_dx9_media_sharing cl_khr_dx9_media_sharing cl_khr_d3d10_sharing cl_khr_d3d11_sharing cl_intel_d3d11_nv12_media_sharing cl_intel_simultaneous_sharing Device OpenCL C Version: OpenCL C 2.1 Device Available: true Device Compiler Available: true Device Linker Available: true Platform Name: Intel(R) OpenCL Platform Vendor: Intel(R) Corporation Platform Version: OpenCL 2.1 Platform Profile: FULL_PROFILE Platform Extensions: cl_intel_dx9_media_sharing cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_d3d11_sharing cl_khr_depth_images cl_khr_dx9_media_sharing cl_khr_fp64 cl_khr_gl_sharing cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_icd cl_khr_image2d_from_buffer cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_spir Device Index: 1 Selected: true Device Name: Intel(R) Core(TM) i3-8130U CPU @ 2.20GHz Device Vendor: Intel(R) Corporation Device Version: OpenCL 2.1 (Build 611) Driver Version: 7.6.0.611 Device Type: cpu Device Extensions: cl_khr_icd cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_depth_images cl_khr_3d_image_writes cl_intel_exec_by_local_thread cl_khr_spir cl_khr_dx9_media_sharing cl_intel_dx9_media_sharing cl_khr_d3d11_sharing cl_khr_gl_sharing cl_khr_fp64 cl_khr_image2d_from_buffer cl_intel_vec_len_hint Device OpenCL C Version: OpenCL C 2.0 Device Available: true Device Compiler Available: true Device Linker Available: true Platform Name: Intel(R) OpenCL Platform Vendor: Intel(R) Corporation Platform Version: OpenCL 2.1 Platform Profile: FULL_PROFILE Platform Extensions: cl_intel_dx9_media_sharing cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_d3d11_sharing cl_khr_depth_images cl_khr_dx9_media_sharing cl_khr_fp64 cl_khr_gl_sharing cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_icd cl_khr_image2d_from_buffer cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_spir
For me, OpenCL on/off doesn't matter for the behaviour, it's the same thing. .bin .exe remain after closing LO. When the start-up center appears after re-launching LO, the first instance disappears. Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: eb3ae3234e098e1ee605624b0cac4c90436628d0 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 22631); UI render: default; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: threaded
(In reply to m_a_riosv from comment #29) > For me, OpenCL on/off doesn't matter for the behaviour, it's the same thing. > > .bin .exe remain after closing LO. > > When the start-up center appears after re-launching LO, the first instance > disappears. I would say that there is a problem there anyway (too). If any user closed LO correctly and completely (and there are no related tools left open either), then there should not be any "first instance lingering until the next time" either. The difference in your case seems to be that the left-overs are limited to one pair of processes only, instead of having additional pairs for each launch-and-close cycle. @Miguel, any notes when trying to Start in Safe Mode, especially when OpenCL is set to ON?
With OpenCL on, it is possible to start in Safe Mode. But always start in Safe Mode, the only way to change is Menu/Help/Restart in Safe Mode to choose the normal mode, but the profile is lost.
With Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 838f6adc9bdde2f656eb26bdc2870adfa7aa412b CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded For me the issue is relation with: Menu/Tools/Options/LibreOffice/General/Load LibreOfficeDev during system start up. If it is disabled, before the first launch, the issue doesn't happen. But it is enabled at launch or on a posterior launch, there is no way to avoid the process remains alive. If it is really an issue. So launch LO Disable the option End the process in the system, or restart the system Launch again LO Close LO The process is closed
(In reply to m_a_riosv from comment #32) > For me the issue is relation with: > Menu/Tools/Options/LibreOffice/General/Load LibreOfficeDev during system > start up. That is probably a different issue, at least partially. Although I never install with Quick Start set to ON, and I never activate it later-on either, based on your comment 32 I just tested setting it ON, saving the change and rebooting, always with OpenCL ON for this test. The result for me is the same as it was before. OpenCL ON > left-over processes after closing. Are any of these (left-over) processes related to Quick Start? OpenCL OFF > no problem. Should I also test having Quick Start set to ON while OpenCL is OFF? What would be the expected behavior regarding (left-over) processes in such case? As requested, I have already posted my opencl log in comment 28. What now?
Entity: line 1: parser error : Document is empty ^ warn:vcl:7624:10548:vcl/source/image/ImplImage.cxx:101: Failed to load scaled image from cmd/sc_signaturesmenu.png at 1 warn:vcl:7624:10548:vcl/source/image/ImplImage.cxx:124: Failed to load stock icon cmd/sc_signaturesmenu.png warn:vcl:7624:10548:vcl/source/image/ImplImage.cxx:101: Failed to load scaled image from cmd/sc_documentation.png at 1 warn:vcl:7624:10548:vcl/source/image/ImplImage.cxx:124: Failed to load stock icon cmd/sc_documentation.png warn:vcl:7624:10548:vcl/source/image/ImplImage.cxx:101: Failed to load scaled image from cmd/sc_safemode.png at 1 warn:vcl:7624:10548:vcl/source/image/ImplImage.cxx:124: Failed to load stock icon cmd/sc_safemode.png warn:vcl:7624:10548:vcl/source/image/ImplImage.cxx:101: Failed to load scaled image from cmd/sc_getinvolved.png at 1 warn:vcl:7624:10548:vcl/source/image/ImplImage.cxx:124: Failed to load stock icon cmd/sc_getinvolved.png warn:vcl:7624:10548:vcl/source/image/ImplImage.cxx:101: Failed to load scaled image from cmd/sc_showlicense.png at 1 warn:vcl:7624:10548:vcl/source/image/ImplImage.cxx:124: Failed to load stock icon cmd/sc_showlicense.png warn:unotools.misc:7624:10548:unotools/source/misc/mediadescriptor.cxx:372: url: 'private:factory/scalc' com.sun.star.ucb.ContentCreationException message: "No Content Provider available for URL: private:factory/scalc at C:/cygwin/home/tdf/jenkins/daily_workspace/tb/src_master/ucbhelper/source/client/content.cxx:205" eError: (com.sun.star.ucb.ContentCreationError) NO_CONTENT_PROVIDER warn:vcl.builder:7624:10548:vcl/source/window/builder.cxx:3522: probably need to implement NotebookBarAddonsMenuMergePoint warn:legacy.tools:7624:10548:sfx2/source/control/bindings.cxx:1770: No cache for OfficeDispatch! warn:legacy.tools:7624:10548:sfx2/source/control/bindings.cxx:1770: No cache for OfficeDispatch! warn:legacy.tools:7624:10548:sfx2/source/control/bindings.cxx:1770: No cache for OfficeDispatch! warn:legacy.tools:7624:10548:sfx2/source/control/bindings.cxx:1770: No cache for OfficeDispatch! warn:vcl.layout:7624:10548:vcl/source/control/fixed.cxx:388: Only endellipsis support for now warn:vcl:7624:10548:vcl/source/window/builder.cxx:736: missing elements of button/menu warn:vcl.gdi.wndproc:7624:10548:vcl/win/app/salinst.cxx:619: ignoring timer event because we are shutting down warn:vcl.gdi.wndproc:7624:10548:vcl/win/app/salinst.cxx:619: ignoring timer event because we are shutting down warn:vcl.gdi.wndproc:7624:10548:vcl/win/app/salinst.cxx:619: ignoring timer event because we are shutting down warn:vcl.gdi.wndproc:7624:10548:vcl/win/app/salinst.cxx:619: ignoring timer event because we are shutting down
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/8a5f822897434cffe1991325ea18014734bfa24e 24, 31." href="show_bug.cgi?id=161048">tdf#161048 Revert "move opencl check at startup inside its own thread" It will be available in 24.8.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.
(In reply to Commit Notification from comment #35) > Noel Grandin committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > 8a5f822897434cffe1991325ea18014734bfa24e Testing with: Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 6084962f93efc005b6827edceae12d3170f17ccd CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: en-US (es_AR); UI: en-US Calc: CL threaded ...built on 2024-05-29, I can launch-and-close LO Dev and I no longer see left-over background processes. I can also use menu Help > Restart in Safe Mode and it restarts automatically as expected. @Miguel, if I may, I would suggest re-testing the steps you reported in comment 31 with a newer build (2024-05-29 or newer).
(In reply to ady from comment #36) > .... > > @Miguel, if I may, I would suggest re-testing the steps you reported in > comment 31 with a newer build (2024-05-29 or newer). Seems now the issue is in relation Menu/Tools/Options/LibreOffice/General/Load LibreOffice during system start-up enabled
Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 6084962f93efc005b6827edceae12d3170f17ccd CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Also with Version: 24.2.0.0.alpha1 (X86_64) / LibreOffice Community Build ID: 06946980c858649160c634007e5fac9a5aa81f38 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: default; VCL: win Locale: es-ES (es_ES); UI: es-ES Calc: threaded
(In reply to m_a_riosv from comment #37) > Seems now the issue is in relation > Menu/Tools/Options/LibreOffice/General/Load LibreOffice during system > start-up > enabled Since I don't use quickstart as a general rule, I am not completely sure about this but I believe that, under such condition, there should be an expected background process. 1. When the quickstart setting is ON, just rebooting shows background processes in Windows' Task Manager. 2. In TM, add/show the column for "Command line" (in Spanish: "Linea de comandos"). With quickstart enabled, the command line would include "--quickstart" (among other possible command line parameters). 3. Launching LO Start Center (first time after reboot) moves the soffice.bin process from background to active. The process for soffice.exe remains in the background. 4. Closing Start Center would revert the situation; both processes are now listed within the background group. 5. Launching and closing LO again should not generate additional background processes; there are always the same two. With quickstart set to OFF, there should be no background processes after closing LO. Please review whether this is really the expected behavior when quickstart is set to ON, also with older versions.