I can't be sure if this is a LO bug, but other programs in my computer don't have this problem. I've experienced this for quite a while but have just decided to report. All is fine, until I resume from hibernation. Somehow, I can no longer launch LO files (ODT, ODS, etc) externally (i.e. from Explorer). Windows attempts to do it, an instance of swriter, scalc, etc. appears in Task Manager, then nothing comes up. If I do this again, another swriter, scalc, etc appears, and no new window with the file I attempt to open. FYI, I can still open files within LO. I can also open by dragging the file to an LO window's title bar. Curiously, if I unload LO from the system and attempt to restart it, nothing shows up, except an instance of soffice.exe in Task Manager. No soffice.bin. To recover from the problem, I have to reboot.
Which Windows version? Win10? 32 or 64 bit Windows? Do you have the the LibreOffice quick starter installed?
(In reply to Dennis Roczek from comment #1) > Which Windows version? Win10? 32 or 64 bit Windows? Win7 64bit > Do you have the the LibreOffice quick starter installed? Yes, but I've only got it running only recently. (Apparently there's another bug, with the LO installation, which doesn't have the LO loaded upon startup, despite having ticked the relevant box.)
This is similar to or the same with Bug 38915(https://bugs.documentfoundation.org/show_bug.cgi?id=38915), which is probably inherited from Openoffice appeared in october 2010. See [Issue] OOo hangs with multiple soffice.exe in Task Manager(https://forum.openoffice.org/en/forum/viewtopic.php?f=15&t=34922&sid=a2f54a34723c4bc76576eccc0959e1a9)，Issue 114963 - multiple instances of soffice.exe(https://bz.apache.org/ooo/show_bug.cgi?id=114963). I am not sure whether hibernation is its cause. I use hibernation everyday. I experiences the same as Kumāra did. Indeed, files can be loaded from within LO, but not externally (by clicking on files in explorer). If killing soffice.* and relevant LO exe in task manager can not solve the problem, logout and login can solve it. I have not tried to reboot the Windows. That instances appear in memory and show no LO screen is similar to the effect of start parameter "--headless" or "--invisible" in that no LO screen is showed. Sometimes I suspect that the bug is from Windows. For no report from Linux. I have tried many times, but could not describe how to reproduce the symptom. For it is diffiuclt to locate where the causing step is. The symptom may disappear a few days, then appear again, and all operations are quite ordinary. Could someone develop a simple log-and-compare method for every launching and ending process, to make the cause-locating easilier, even it may slow down the performance? For the moment, I uninstalled three components I used to installed (activex controller, explorer extension, dictionary), to see whether the symptom appears or not. Windows 8 64 bit, Libreoffice 5.0.0.5 64 bit.
(In reply to wck317 from comment #3) > This is similar to or the same with Bug > 38915(https://bugs.documentfoundation.org/show_bug.cgi?id=38915), which is > probably inherited from Openoffice appeared in october 2010. See [Issue] OOo > hangs with multiple soffice.exe in Task > Manager(https://forum.openoffice.org/en/forum/viewtopic. > php?f=15&t=34922&sid=a2f54a34723c4bc76576eccc0959e1a9)，Issue 114963 - > multiple instances of > soffice.exe(https://bz.apache.org/ooo/show_bug.cgi?id=114963). Yes, I've seen 2 sets of soffice.exe and soffice.bin. > Sometimes I suspect that the bug is from Windows. That's what I thought too. That's why I didn't report earlier. And maybe it is.
Created attachment 118032 [details] Soffice.bin threads (faileded to open odt by right click odt in Win Explorer)
Created attachment 118033 [details] Soffice.bin threads (succeeded to open odt by right click odt in Win Explorer)
Created attachment 118034 [details] Soffice.bin (failed ...) thread main's stack
I wrote much fewer than before in the last ten days. I tried to open many files (odt, odc, odp, odb) and closed them , no multiple instances occured. I did not edit files. That is, I did not test under a complete conditions. Then I installed activex controller, explorer extension, English and German dictionary again. No quickstart is installed. My Asus Laptop runs "Instant On" program so that it did not enter into hibernation, rather into stand by. This is what I used everyday. I must correct what I have said. I let process explorer open everyday in order to see whether mutiple instances occur. Today I encountered an invisible instance. Libreoffice： 5.0.1.1 (x64), Windows 8(x64) The first set One odt file was edited (simply entered words, went around, deleted, copied, pasted, ctrl-s (saved)) last night. soffice.exe and soffice.bin were in memory. This was the first set. Entered into stand-by last night. Resumed from stand-by today. soffice.exe's command line: "C:\Program Files\LibreOffice 5\program\soffice.exe" soffice.bin's: "C:\Program Files\LibreOffice 5\program\soffice.exe" "-env:OOO_CWD=2C:\\Program Files\\LibreOffice 5". It consumed about 60 MB. The second set Right-clicked another odt file in Windows explorer today. It was not opened. Another set of LO program appeared in memory: swriter.exe, soffice.exe, soffice.bin. This is the second set. Soffice.bin is invisible on screen and its memory consumption is much smaller, about 5 MB. swriter.exe's command line: "C:\Program Files\LibreOffice 5\program\swriter.exe" -o "pathname", soffice.exe's: "C:\Program Files\LibreOffice 5\program\swriter.exe" -o "pathname" --writer, soffice.bin's: "C:\Program Files\LibreOffice 5\program\swriter.exe" "-o" "pathname" "--writer" "-env:OOO_CWD=2filepath" (where instead "\", "\\" were used) Open file from within Tried to open another odt or ods file from within LO through "File > open" or "file > recent documents", it succeeded. No other set(swrite.exe/scalc.exe, soffice.exe, soffice.bin) was created. Soffice.bin in the first set consumed more memory now while the memory consumption of the second set remained no change. Open file from outside Now right-clicked another odt file in Windows explorer. I thought it should not be opened in this way, but it was opened. It seems that the last successful opening changed the status. The second set remained unchanged in its memory consumption. Close the first set with ctrl-q I closed (visible) LO with ctrl-q. The first set disappeared from memory. The second set remained. The third set Right-clicked an odt file in Windows explorer. It was opened. Another set appear in memory. Details of command lines: swriter.exe: "C:\Program Files\LibreOffice 5\program\swriter.exe" -o "pathname" soffice.exe: "C:\Program Files\LibreOffice 5\program\swriter.exe" -o "pathname" --writer "C:\Program Files\LibreOffice 5\program\swriter.exe" "-o" "pathname" "--writer" "-env:OOO_CWD=2filepath" This is different from the first set because the file is opened from outside. If it is opened from within soffice, the set shall be similar that of the first. With ctrl-q, LO is quitted. The third set disappeared from memory. The second remained in memory. The fouth set Clicked soffice icon and opened an odt file from within. It succeeded. The fouth set appeared in memory. With ctrl-q, LO is quitted and the fourth set disappeared from memory. The second set remained. The fifth set Right-clicked an odt file in Windows explorer. It was opened successfully. Soffice.bin's threads are as follows: Soffice.bin threads (succeeded to open odt by right click odt in Win Explorer).png It differed in considerable degree from soffice.bin's threads in the second set which showed in the attached picture: Soffice.bin threads (faileded to open odt by right click odt in Win Explorer).png. Entered into stand by. Resumed from it. Right-clicked an odt file in Windows explorer. It was opened successfully. No other set appeared in memory. It was not more than two sets of LO processes in memory. But I have seen more than two sets in memory. I guess that procedure to generate more than two sets differed in steps from the above mentioned. For the first (invisible) set stack of thread 5416 swriter.exe+0x1388 (almost the same with that of a noraml set) ntdll.dll!NtWaitForSingleObject+0xa KERNELBASE.dll!WaitForSingleObjectEx+0x9a swriter.exe+0x1964 stack of thread 4860 sofice.exe+0x24f4 (almost the same with that of a noraml set) ntdll.dll!NtWaitForMultipleObjects+0xa KERNELBASE.dll!GetTickCount+0x4e USER32.dll!GetWindowLongPtrA+0x21a soffice.exe+0x1bbc soffice.exe+0x240e KERNEL32.DLL!BaseThreadInitThunk+0x1a ntdll.dll!RtlUserThreadStart+0x21 stack of thread 4752 !main+0x200 (differs in considerable degree from that of a noraml set) (Not "soffice.bin!main+0x200", just "!main+0x200". Without "soffice.bin". See Soffice.bin (failed ...) thread main stack.png. !RtlCommitDebugInfo+0x84 seems to increase in thread number with every looking in.) !NtWaitForSingleObject+0xa !RtlMultiAppendUnicodeStringBuffer+0x38e !RtlInitializeCriticalSection+0x125 !RtlGetOwnerSecurityDescriptor+0x137 !CommandLineToArgvW+0x10e3 !SHGetFolderPathW+0x19b !PathIsExeWorker+0x4174 !PathIsExeWorker+0x3f4d !PathIsExeWorker+0x5995 !PathIsExeWorker+0x49d7 !PathIsExeWorker+0x623d !SHCoCreateInstanceWorker+0x1180 !SHGetFolderPathEx+0x80 !SHGetFolderPathWWorker+0x101 !SHGetFolderPathW+0x49 !SHGetFolderPathAWorker+0x40 !SHGetFolderPathA+0x43 !SHGetSpecialFolderPathAWorker+0x27 !SHGetSpecialFolderPathA+0x3b !osl_writePipe+0x254 !osl_getConfigDir+0x67 !rtl_reallocateMemory+0x670a !rtl_reallocateMemory+0x6c47 !rtl_reallocateMemory+0x5674 !rtl_reallocateMemory+0x7383 !rtl_reallocateMemory+0x582c !rtl_reallocateMemory+0x5c6e !rtl_reallocateMemory+0x68b1 !rtl_reallocateMemory+0x6c47 !rtl_reallocateMemory+0x52ef !rtl_bootstrap_expandMacros+0x3c !EmbeddedFontsHelper::clearTemporaryFontFiles+0x4b !InitVCL+0x3b !DeInitVCL+0x6e4 !SVMain+0x32 !soffice_main+0x75 !main+0x35d !BaseThreadInitThunk+0x1a !RtlUserThreadStart+0x21 a normal (visible) set stack of thread 2384 swriter.exe+0x1388 ntdll.dll!NtWaitForSingleObject+0xa KERNELBASE.dll!WaitForSingleObjectEx+0x9a swriter.exe+0x1964 stack of thread 5566 soffice.exe+0x24f4 ntdll.dll!NtWaitForMultipleObjects+0xa KERNELBASE.dll!GetTickCount+0x4e USER32.dll!GetWindowLongPtrA+0x21a soffice.exe+0x1bbc soffice.exe+0x240e KERNEL32.DLL!BaseThreadInitThunk+0x1a ntdll.dll!RtlUserThreadStart+0x21 stack of thread 5308 soffice.bin!main+0x200 USER32.dll!IsThreadDesktopComposited+0x2fa USER32.dll!GetMessageW+0x25 mergedlo.dll!vcl::IsWindowSystemAvailable+0x7439 mergedlo.dll!vcl::IsWindowSystemAvailable+0x7eac mergedlo.dll!Application::Execute+0x7e mergedlo.dll!cppu::WeakImplHelper2<com::sun::star::lang::XServiceInfo,com::sun::star::frame::XTerminateListener>::operator=+0x4648 mergedlo.dll!DeInitVCL+0x6f9 mergedlo.dll!SVMain+0x32 mergedlo.dll!soffice_main+0x75 soffice.bin+0x102e soffice.bin!main+0x35d KERNEL32.DLL!BaseThreadInitThunk+0x1a ntdll.dll!RtlUserThreadStart+0x21 As having already seen, I could not reproduce the steps for bug-occurence. Thank you for your patience for reading this to end.
(In reply to wck317 from comment #8) <snip> > Entered into stand by. Resumed from it. Right-clicked an odt file in Windows > explorer. It was opened successfully. No other set appeared in memory. <snip> > As having already seen, I could not reproduce the steps for bug-occurence. > Thank you for your patience for reading this to end. Thanks, but since you're referring to a different issue, multiple "soffice" after stand by, we can't go by this for this bug. I wish to add that this usually happens only after a few rounds of resuming from hibernation. I can't ascertain the pattern as yet.
Kumāra: are you still seeing this is in 5.2.x? If you are, you could try this: https://wiki.documentfoundation.org/UserProfile#Resolving_corruption_in_the_user_profile Set to NEEDINFO. Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED WORKSFORME, if the problem went away.
Dear Bug Submitter, 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-20170628
I've not seeing this for quite some while. So, I'm closing this.