Multiple instances of soffice.bin and soffice.exe are allowed. They are not always properly closed when exiting LibreOffice. This causes the launch of a new LibreOffice to fail, or perhaps take a super long time. I opened the task manager and discovered six instances of soffice.bin and soffice.exe. Killing an instance of soffice.bin resulted in another instance of its creation. The necessary sequence to killing the multiple processes was to first kill soffice.exe then the soffice.bin was not regenerated. After killing all soffice.exe and all soffice.bin instances, then starting LibreOffice occured normally.
@Joseph Conner: Please contribute compete information concerning your WIN. I have been used to see that problem with WIN XP, but since I changed to WIN7 64 bit it seems that the problem has vanished.
My OS: Name : Microsoft Windows XP Professional|C:\WINDOWS|\Device\Harddisk0\Partition1 Description: WinXP Manufacturer : Microsoft Corporation Version : 5.1.2600 CSD Version : Service Pack 3 Windows Directory : C:\WINDOWS System Directory : C:\WINDOWS\system32 System BootDevice : \Device\HarddiskVolume1 Total Virtual Memory : 2097024 KB Total Visible Memory : 2031088 KB Free Physical Memory : 558224 KB Free Virtual Memory : 2056492 KB Build Type : Uniprocessor Free LastBootUpTime : 07 / 01 / 2011 Current Time Zone : Mountain Time (US & Canada) , Arizona Install Date : 09 / 03 / 2007 SerialNumber : 55274-OEM-0015393-82121 Status : OK My Computer Hardware: Name : AMD Athlon(tm) 64 Processor 3200+ Description: x86 Family 15 Model 44 Stepping 2 Manufacturer : AuthenticAMD Version : Model 12, Stepping 2 DataWidth : 32 Bits Socket Designation : Socket 754 Type : Central Processor CPU Id : 078BFBFF00020FC2 CPU Family : Unknown CPU Stepping : 2 Load Percentage : 27 % Max ClockSpeed : 2210 MHz Current ClockSpeed : 2210 MHz Voltage : 1.4 V External Clock : 201 MHz Upgrade Method : undefined L2 Cache Size : 512 Kb Display Availability : Running/Full Power PowerManagement Supported : false Status : OK Name : Physical Memory Memory Capacity : 8192MB Memory BankLabel : Bank0/1 Memory TotalWidth : 64 Bits DataWidth : 64 Bits Memory DeviceLocator : A0 Memory Type : Unknown Name : Physical Memory Memory Capacity : 8192MB Memory BankLabel : Bank2/3 Memory TotalWidth : 64 Bits DataWidth : 64 Bits Memory DeviceLocator : A1 Memory Type : Unknown VIDEO: Name : VIA/S3G UniChrome Pro IGP Display Availability : Running/Full Power Video Mode : 1280 x 1024 x 4294967296 colors Adapter DAC Type : Internal Current Horizontal Resolution : 1280 Pixels Current Vertical Resolution : 1024 Pixels Current Number Of Colors : 4294967296 Adapter RAM : 64 MB Current Refresh Rate : 60 Hertz Video Processor : VIA/S3G UniChrome Pro IGP Inf Filename : oem22.inf Driver Version : 6.14.10.0364-22.00.01j Monochrome : false Installed Display Drivers : vtdisp.dll Status : OK BIOS: Name : Phoenix - AwardBIOS v6.00PG Manufacturer : Phoenix Technologies, LTD Version : VIAK8M - 42302e31 SerialNumber : ReleaseDate : 01 / 20 / 2006 Target Operating System : Unknown Language : n|US|iso8859-1 Status : OK If you need anything additional please let me know and I will provide it. Thank you.
I see the same problem on a Windows 7 64 bit machine. [Résumé système] Élément Valeur Système d’exploitation Microsoft Windows 7 Édition Familiale Premium Version 6.1.7601 Service Pack 1 Build 7601 Informations supplémentaires Non disponible Éditeur Microsoft Corporation Ordinateur DESKTOP-CMH Fabricant Dell Inc. Modèle Inspiron 580 Type PC à base de x64 Processeur Intel(R) Core(TM) i3 CPU 550 @ 3.20GHz, 3200 MHz, 2 cœur(s), 4 processeur(s) logique(s) Version du BIOS/Date Dell Inc. A07, 13/11/2010 Version SMBIOS 2.6 Répertoire Windows C:\Windows Répertoire système C:\Windows\system32 Périphérique de démarrage \Device\HarddiskVolume2 Option régionale France Couche d’abstraction matérielle Version = "6.1.7601.17514" Utilisateur DESKTOP-CMH\charmian Fuseaux horaires Paris, Madrid (heure d’été) Mémoire physique (RAM) installée 4,00 Go Mémoire physique totale 3,87 Go Mémoire physique disponible 2,97 Go Mémoire virtuelle totale 20,9 Go Mémoire virtuelle disponible 18,8 Go Espace pour le fichier d’échange 17,0 Go Fichier d’échange C:\pagefile.sys Let me know if I can provide additional information which might help to identify and correct this very annoying issue.
Is anyone working on this?
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
needinfo keyword redundant by needinfo status.
I have seen this a lot with OOo 3.x (3.3 especially) and remember to see it happen a few times with LO 3.3 and early 3.4 versions, but it didn't happen to me lately, so it seems to be fixed by some changes in the later 3.4 and/or 3.5 versions.
My wife and I both continue to have multiple instances of soffice.bin and soffice.exe whenever LibreOffice is NOT open and I double-click on a file from Windows Explorer that needs to be translated, i.e., .doc, .docx, .xls, .xlsx., .rtf, etc. She has a Windows 7 laptop and I have a Windows 7 desktop. It doesn't seem to matter what else is open. OS Name Microsoft Windows 7 Home Premium Version 6.1.7601 Service Pack 1 Build 7601 Other OS Description Not Available OS Manufacturer Microsoft Corporation System Name USER-PC System Manufacturer Gateway System Model DX4831 System Type x64-based PC Processor Intel(R) Core(TM) i5 CPU 650 @ 3.20GHz, 3201 Mhz, 2 Core(s), 4 Logical Processor(s) BIOS Version/Date American Megatrends Inc. P01-A0, 11/17/2009 SMBIOS Version 2.6 Windows Directory C:\windows System Directory C:\windows\system32 Boot Device \Device\HarddiskVolume2 Locale United States Hardware Abstraction Layer Version = "6.1.7601.17514" User Name user-PC\user Time Zone Eastern Daylight Time Installed Physical Memory (RAM) 8.00 GB Total Physical Memory 7.93 GB Available Physical Memory 6.01 GB Total Virtual Memory 15.9 GB Available Virtual Memory 13.8 GB Page File Space 7.93 GB Page File C:\pagefile.sys
Dear bug submitter! Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs. To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem. Yours! Florian
The problem persists, only after killing all soffice.exe and all soffice.bin instances over the Taskmanager starting LibreOffice again normally. It is difficult to reproducte this because there is no feedback why the first process is blocked or crashing. Frequently occur this if the quickstart is open
@Joseph Conner Please consider: <http://wiki.documentfoundation.org/BugReport_Details#Version> Please do not touch the dashboard without knowing for what the switch levers are ;-)
Confirmed on Windows 7 64 bits with LibreOffice 5.0.4. Perhaps related to a bug on AOO on Windows.
Please apply this patch https://bz.apache.org/ooo/show_bug.cgi?id=114963
It is some interesting research from aptitude - in general, I'd suggest that someone clueful in this area (eg. Stephan) looks at his re-ordering of those two lines, and that we commit a smaller patch (with git there is no need for all that commenting in-line) - and credit aptitude for the insight in the commit msg text.
Created attachment 123199 [details] dubbed instances
We use LO/OOo COM-object to import some excel files in our app. Maybe it causes the issue when using LO applications and COM-object at the same time? But it is very diffucult to reproduce. Also getting this issue on Win7 Home x64 LibreOffice 5.1.0.3 (JRE 7.65) and less versions. Also note dubbed instances on Win7 Pro x86 LibreOffice 4.4 (no JRE) ~10 workstations. I tried to reproduce the issue on Win7 Pro x64 LO 4.4 and 5.0.5 but there is no result(
*** Bug 100668 has been marked as a duplicate of this bug. ***
Hi, We have this issue on a very frequent basis (rougly 40% of the hotline calls, that's around 100 calls a month for 5000 users). It is present in version 5.0.3 and 5.1.5.2 (x64) on Windows. It seems to occur every day on some machines and never on others, Regards, Eric Ficheux
BTW, The bug I marked as duplicate has a link to a fix but for OpenOffice ... Regards, Eric Ficheux
(In reply to Vasily Maryutenkov from comment #16) > Please apply this patch https://bz.apache.org/ooo/show_bug.cgi?id=114963 included on master towards LO 5.3 as <https://cgit.freedesktop.org/libreoffice/core/commit/?id=74ac65c49cc1d53b1aa93c2b7c720255867aace2> "#i114963# Enable IPC before OpenClients to allow client connections when printing."
Thx Stephan, Do you know if there will be a port to branch 5.2? Regards, Eric Ficheux
This patch to Enable IPC thread before OpenClients needs functional testing before a backport to 5.2 https://cgit.freedesktop.org/libreoffice/core/commit/?id=74ac65c49cc1d53b1aa93c2b7c720255867aace2 #i114963# Enable IPC before OpenClients to allow client connections when printing. Patch By: aptitude@btconnect.com It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hi, I plan to test the fix in the development build this week with a few users that report having the problem everyday. I'll give feedback about the results. Can this help with functional testing? Regards, Eric Ficheux
Hi, I got new information from my users: version 5.1.5 significantly decreases the problem frequency (no new reports from 30 upgraded users), which is unexpected since there is no report of the bug being fixed on 5.1.5 ... The previous user reports I got were about version 5.0.3 freezing but users mistakenly reported being on version 5.1.5 Regards, Eric Ficheux
Hello, Is this bug fixed? If so, could you please close it as RESOLVED FIXED?
I upgraded my operating system from windows to Ubuntu Linux and I use LibreOffice 5.2.3. I cannot therefore validate the existence or non existence of the problem of multiple instances of soffice.exe since that is a windows executable. So if someone still using windows wants to close it as "works for me" or some such, have at it.
It happend to me only once or twice with the 5.2 branch (Win 10 64 Bit). So the frequency decreased but the bug still seems to be there. Kind regards Dieter
Hi, I can confirm that this bug is present in version 5.3.0.3 (compilation ID 7074905676c47b82bbcfbea1aeefc84afe1c50e1) running in a Windows 7 enterprise 64 bits.
I have a feeling it is the way we call on TerminateProcess in OSL. I'm wondering if this might be fixed in my proposed patch I reference in bug 106489 and that I've submitted the following proposed patch on gerrit: https://gerrit.libreoffice.org/#/c/35071/
Hello. I have this issue too on w2k8r2 terminal servers and LO 5.3.0.3 User need to manually close LO processes to get it working. Is there some recommendations on how to collect more info in case of having this problem? I mean something to do when i already have this happened. I can not run tools like process monitor on my terminal servers to catch the moment of problem happened. Maybe some instructions for using debugger if it can help?
My suspicion is that application keeps waiting for a message to arrive in its windows message loop. Specifically, in GetMessageW() inside ImplSalYield() (see http://opengrok.libreoffice.org/xref/core/vcl/win/app/salinst.cxx#585). A patch is in gerrit: https://gerrit.libreoffice.org/39996 To check if this is true, one may try sending any message to any window (they are hidden at that moment) of the hung process, using something like StefanTools' SendMessage (http://stefanstools.sourceforge.net/SendMessage.html). If I'm right, then this should make the process close normally. However, I'm not sure that fixing this specific point is total solution, because there might be other waiting points in the code.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f054b9187155bc32b7d06808aea87127cb0a3a4f tdf#38915: don't wait on message queue if application already has quit. It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I tried the latest 6.0 dev build from daily builds but the problem still exists. Before closing hanging soffice.exe 's the new instance wont do anything.
I asked to test the hanging issue. Please use some application to *post* any message to any window (of classes SALFRAME or SALCOMWND) of hung soffice.bin, and see if that resolves it (it should wake up, process the message and close itself successfully). If it is so, then it's fruitful to look for such loops and resolve them one by one. If not, then the problem is in another place. Without active user help (aside from simple tests if current nightly works) it's *extremely* difficult to solve issues like this. Btw: from comment 36, it looks like soend has some reliable reproducing steps? If so, then please share them as detailed as possible.
Created attachment 139228 [details] Backtrace Found a straightforward case of this with the following steps: - Kill a running soffice.bin, so the document recovery is started next time. - Start soffice twice. => First time the document recovery dialog comes up, but with the second a new process is started, and it remains as a zombie even after you move on with the document recovery and eventually exit the application. Attaching backtrace.
(In reply to Aron Budea from comment #38) > Found a straightforward case of this with the following steps: > - Kill a running soffice.bin, so the document recovery is started next time. > - Start soffice twice. A correction here, the second time it's important to start one of the applications, otherwise then start center will open "normally" (it's not the expected behavior, though). Revised steps: - Kill a running soffice.bin, so the document recovery is started next time. - Start soffice, note the document recovery. - Start any of the applications, eg. soffice --writer.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=cf333a878ceed18d0343520a2c65be69fc433b1f tdf#38915: set cProcessed condition on any process outcome It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://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-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=30f07eb1d412fd53da70f350322034aae5b9c561&h=libreoffice-6-0 tdf#38915: set cProcessed condition on any process outcome It will be available in 6.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://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 ? Thanks
(In reply to Xisco Faulí from comment #42) Well... let's call this heizenbug fixed :) - we can only be sure when there's no duplicates for newer versions.
(In reply to Mike Kaganski from comment #37) > I asked to test the hanging issue. Please use some application to *post* any > message to any window (of classes SALFRAME or SALCOMWND) of hung > soffice.bin, and see if that resolves it (it should wake up, process the > message and close itself successfully). If it is so, then it's fruitful to > look for such loops and resolve them one by one. If not, then the problem is > in another place. > > Without active user help (aside from simple tests if current nightly works) > it's *extremely* difficult to solve issues like this. > > Btw: from comment 36, it looks like soend has some reliable reproducing > steps? If so, then please share them as detailed as possible. I have win 2k8r2 server with LO 5.3.7.2 and this issue repeat too much times. I tried *send* any post with SendMessage tool, like WM_ENDSESSION to process "soffice.bin" calss "SALCOMWIND", but SendMessage dialog is freezing and windows prompt me to force close this app. And LO is continue hiding run in processes. Any anoter messages to this process\class ending same. And i am dont have process "soffice.bin" with class "SALFRAME", and posting any messages to any another classes of process "soffice.bin" return code 0, but dont get any reaction from LO.
(In reply to Shestakoff Alexander from comment #44) > I have win 2k8r2 server with LO 5.3.7.2 and this issue repeat too much times. Please don't change the status of the bug, unless you test with the last version. The bug is supposed to be fixed in 6.0, with the last commits listed here in comment 40 and comment 41.
*** Bug 121115 has been marked as a duplicate of this bug. ***