This is a bug report for a bug that has existed at least since March 2013. I just didn't get around to reporting it until now, as I chose just to use Word instead of LibreOffice. I am using the excellent Clipboard Help+Spell program (http://www.donationcoder.com/Software/Mouser/clipboardhelpandspell/) and have it running constantly in the background. When I use LibreOffice, and Clipboard Help+Spell is running in the background, it very often happens that they both go into a deadlock with each other. By "very often" I mean every 5 or 10 minutes, sometimes more often, sometimes less often. The UI freezes completely in both applications, and I have to kill one of the processes (either one will do) to release the deadlock. The processes I kill are either soffice.bin or ClipboardHelpAndSpell.exe. When I kill one of those processes, the other program immediately unfreezes and continues without any problems. But of course I lose data every time I do that, either from LibreOffice or Clipboard Help+Spell, as they do not get a chance to save their state. The mutual deadlock is detectable and provable. I will attach screenshots from Resource Monitor and Process Explorer taken 2013-11-04. "Baglås" is Danish for "deadlock". The processes focused are those with the process IDs mentioned by Resource Monitor. They both seem to say "State: Wait:WrUserRequest", but I am not knowledgable enough to know if that tells anything. I do not remember which version of LibreOffice it was. But the same thing still happens in LibreOffice 4.4.7. I guess I could take new screenshots, but the problem is exactly the same, so I currently see no reason to do that. If someone can provide me with a good reason to do it, I could take new screenshots. I know for certain that the deadlock happened already back in March 2013, and that it happened in 4.0.1.2, 4.4.0 Beta 1, and currently 4.4.7.2 and that it has been a constant nuisance for me. It is the most important reason why I normally use Word instead of LibreOffice; I cannot have my word processor crash/freeze all the time. My word processor should be extremely stable, like Microsoft Word actually is. And I use Clipboard Help+Spell constantly, so not using that program is not a viable option either. As both Clipboard Help+Spell and LibreOffice go into a mutual deadlock, there is of course a bug in both programs, as no program should ever go into a deadlock with another program. If a resource needs to be waited for, it should always time out after a short while, giving the control back to the program. The program can then try again, repeatedly, but it should always give the user the option to give up that specific task, especially if it delays the user. In any case, the *user interface* should never freeze in wait for a resource, not even during a short wait. So blaming the other program would be unproductive. There is definitely a bug in LibreOffice. A similar bug is just also present in Clipboard Help+Spell. I have and have never had similar problems with interactions between any of the many other programs I use, even though Clipboard Help+Spell is running all the time. I only have the problem when LibreOffice and Clipboard Help+Spell are running at the same time. They always end up in a mutual deadlock. I have tried sorting out the problem with the author of Clipboard Help+Spell, as that would "solve" the bug in Clipboard Help+Spell and therefore solve the problem for me personally (if just one of the programs behaved correctly, the deadlock would not occur), but even though he was extremely helpful, I gave up in the end because I had to test it too much, as he could not reproduce the deadlock on his computer. I have experienced the problem on three different computers, two running Windows 7 SP1 64-bit and my current one running Windows 10. It is not possible for me to test it under other versions of Windows; I only have access to Windows 7 64-bit and Windows 10. The three mentioned computers were my most recent main computers. The deadlock *seems* to happen randomly. Of course it is not random, but I have failed to find a pattern, even though I have tried. It doesn't especially happen when I copy or paste text. It can happen when I am just writing normally in LibreOffice without using the clipboard. I do not have to issue any specific command in either LibreOffice or Clipboard Help+Spell for it to happen. It can happen seemingly out of the blue. Or it can not happen. But in general it happens, as I said, at least every 5 or 10 minutes, and especially when I am really working with writing a text in LibreOffice. Of course I have thought that it "must" be clipboard related, because Clipboard Help+Spell is a clipboard program that monitors the clipboard, but I did not find any pattern to that. Copying and pasting can go perfectly fine, like all other commands. No specific command seems to trigger it. So I guess it must be some kind of background process that triggers it. Maybe in combination with some unlucky timing, so it only happens one time out of a hundred. In any case there is a bug in LibreOffice, and this bug is absolutely the reason why I rarely use LibreOffice even though I would love to use it as my main word processing program. The bug triggers data loss, and that is of course not acceptable for a word processor. By the way, I am not using version 5.0 or 5.1 of LibreOffice, as those versions have another serious bug (Bug 94897) that makes them useless to me. Therefore I have to use 4.4.7. But since I can find no description of this bug anywhere in Bugzilla, the probability of it having been solved in 5.0 or 5.1 is probably rather low. I don't know if anyone can help solving this bug, but I thought at least I would report it. If anyone can guide me how to compile LibreOffice on my computer and tell me how to debug it, perhaps I could find the actual point in the code were the deadlock happens. I am a programmer, but I don't have any experience compiling LibreOffice, much less debugging it.
Created attachment 122794 [details] Deadlock shown by Resource Monitor
Created attachment 122795 [details] Deadlock shown by Resource Monitor
Created attachment 122796 [details] One of the processes mentioned to take part in the deadlock
Created attachment 122797 [details] The other of the two processes mentioned to take part in the deadlock
You can debug with Visual Studio or WinDbg: https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg For setting up a dev environment on Windows: https://wiki.documentfoundation.org/Development/lode You also need to have Visual Studio installed. A more manual way of setting things up: https://wiki.documentfoundation.org/Development/BuildingOnWindows
Thanks, I will have a look into that. Maybe lode will be helpful. I never really could get the environment up running last time I tried a year ago or so. Now there is new hope.
(In reply to jhertel from comment #6) > Thanks, I will have a look into that. Maybe lode will be helpful. I never > really could get the environment up running last time I tried a year ago or > so. Now there is new hope. Yep, be extra careful with the steps, though. I think last time I missed this and it bit me on the butt: The setup program does not automatically adjust your .bashrc, since that may not be desirable in your environment. You need to make the necessary adjustment and make sure that the shell environment conforms to the requirements. (In general the main need is to have LODE_HOME defined and pointing to your lode installation)
(In reply to Beluga from comment #7) > Yep, be extra careful with the steps, though. I think last time I missed > this and it bit me on the butt: > > The setup program does not automatically adjust your .bashrc Thanks a lot for the tip. I did actually notice that one and adjusted my .bashrc correspondingly. I hope I won't miss anything else. Until now everything went fine, except I had to make a few adjustments to the instructions to make them more clear and unambiguous. For instance it said nowhere that the JDK had to be 32-bit. But I am improving the instructions as I go along so those that come after me will hopefully have an easier time setting the whole thing up. I have just started the build, so let's see how it goes.
Well, the build was unsuccessful. And just from reading the instructions, I would have no idea whether the setup process doesn't work, or there is a current bug in LibreOffice master that makes it unbuildable. A lot of building went fine (19,475 log lines), but then this: " Creating library C:/LibreOfficeDev/lode/dev/core/workdir/LinkTarget/Library/ivcl.lib and object C:/LibreOfficeDev/lode/dev/core/workdir/LinkTarget/Library/ivcl.exp [build CXX] accessibility/source/extended/accessiblelistboxentry.cxx OpenGLHelper.o : error LNK2019: unresolved external symbol "__declspec(dllimport) public: static void __cdecl CrashReporter::AddKeyValue(class rtl::OUString const &,class rtl::OUString const &)" (__imp_?AddKeyValue@CrashReporter@@SAXABVOUString@rtl@@0@Z) referenced in function "public: static bool __cdecl OpenGLHelper::isVCLOpenGLEnabled(void)" (?isVCLOpenGLEnabled@OpenGLHelper@@SA_NXZ) C:/LibreOfficeDev/lode/dev/core/instdir/program/vcllo.dll : fatal error LNK1120: 1 unresolved externals mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "C:/LibreOfficeDev/lode/dev/core/instdir/program/vcllo.dll". Den angivne fil blev ikke fundet. [The specified file wasn't found] C:/LibreOfficeDev/lode/dev/core/vcl/Library_vcl.mk:20: recipe for target 'C:/LibreOfficeDev/lode/dev/core/instdir/program/vcllo.dll' failed make[1]: *** [C:/LibreOfficeDev/lode/dev/core/instdir/program/vcllo.dll] Error 96 make[1]: *** Waiting for unfinished jobs.... Makefile:249: recipe for target 'build' failed make: *** [build] Error 2" Which is of course complete nonsense to someone that does not already know the LibreOffice source code. And as a newcomer, I don't even want to know why C:/LibreOfficeDev/lode/dev/core/instdir/program/vcllo.dll does not exist. I want to solve or investigate a specific bug, and not something completely unrelated. I can see now by looking around that http://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER&brief-log=1456661833.19143 shows that exact error in the latest build, so this time it is actually a bug in the LibreOffice code that makes the build fail. But just from following the instructions, I wouldn't know that. I guess the problem is that the setup process describes how to build the bleeding edge master, which is often unbuildable, and not a version that has actually been proven to be buildable. As a newcomer, you will have no idea whether a failed build was due to something that was set up wrong on your machine or due to an actual bug in the current master LibreOffice code that simply makes it impossible to build. That's frustrating. So, I am thinking that at least the process should tell the newcomer to have a look at the current status of the correct column of http://tinderbox.libreoffice.org/MASTER/status.html first, before even trying to build. Currently there are three different Windows versions mentioned, and a newcomer will have no idea what they are trying to build, so the instructions should tell which column to look at. Personally, I still don't know which column it is. But I believe it would be even better to make the setup instructions tell the newcomer how to build a version that is actually known to be buildable (and buildable in the specific environment that the user was instructed to set up). Because then he or she can check that everything is set up correctly for building. In that way the newcomer would know whether a failed build was caused by failing to set up the environment correctly, or whether the LibreOffice code itself is unbuilable. That would take away a lot of frustration. Is there a git tag or similar for the latest buildable version of LibreOffice? I believe a newcomer should have an initial easy success experience, always being able to build LibreOffice by following simple and clear instructions. After that, he or she can learn more and become more accustomed to the intricate details of LibreOffice source code and build environment, but there shouldn't be a steep learning curve just to make a first successful build. It should just work if the instructions are followed. I would love to improve the instructions to at least tell the user to check Tinderbox before building, but being one of those newcomers I am talking about, I still don't have enough information. Which build do the initial setup instructions on https://wiki.documentfoundation.org/Development/lode tell the newcomer to set up? Jenkins_Win64_Dbg, Jenkins_Windows or Jenkins_Windows_Dbg?
Adding Jan I. to CC. Jan, could you look at comment 9. jhertel has kindly been improving the wiki tech docs and now needs your help :)
(In reply to jhertel from comment #9) > bleeding edge master, which is often unbuildable, master is buildable most of the time, and people take it very seriously. The current situation is an exception (because people are away at weekend etc.) > So, I am thinking that at least the process should tell the newcomer to have > a look at the current status of the correct column of > http://tinderbox.libreoffice.org/MASTER/status.html first, before even > trying to build. It is already: https://wiki.documentfoundation.org/Development/BuildingOnWindows#Buildability_of_.27master.27 > Is there a git tag or similar for the latest buildable version > of LibreOffice? No. Just look at tinderbox.libreoffice.org or ci.libreoffice.org. > Which build do the initial > setup instructions on https://wiki.documentfoundation.org/Development/lode > tell the newcomer to set up? Jenkins_Win64_Dbg, Jenkins_Windows or > Jenkins_Windows_Dbg? None of them in particular. It depends on the flags you pass to autogen.sh and/or your compiler, e.g. something might fail in debug build only, or fail for MSVC 2013 but not for 2015 etc.
(In reply to Maxim Monastirsky from comment #11) > master is buildable most of the time, and people take it very seriously. The > current situation is an exception (because people are away at weekend etc.) Good it is taken seriously. But a newcomer would likely start their first build precisely during weekends or holidays where he or she has the time... > It is already: > https://wiki.documentfoundation.org/Development/ > BuildingOnWindows#Buildability_of_.27master.27 Thank you. Then I need to add that section to (or refer to it in) https://wiki.documentfoundation.org/Development/lode, which was the procedure I followed and was recommended to follow. > > Is there a git tag or similar for the latest buildable version > > of LibreOffice? > No. Just look at tinderbox.libreoffice.org or ci.libreoffice.org. Thanks for the pointers. It is not immediately clear from those pointers how to see it, though. Again, I am a newcomer and also want to describe a process that a newcomer can actually follow to get a successful build. I believe the details of learning all those things should come after the successful build. Otherwise newcomers will be put off by unnecessary initial complexity. > > Which build do the initial > > setup instructions on https://wiki.documentfoundation.org/Development/lode > > tell the newcomer to set up? Jenkins_Win64_Dbg, Jenkins_Windows or > > Jenkins_Windows_Dbg? > None of them in particular. It depends on the flags you pass to autogen.sh > and/or your compiler, e.g. something might fail in debug build only, or fail > for MSVC 2013 but not for 2015 etc. Except that I specifically referred to the recommended instructions at https://wiki.documentfoundation.org/Development/lode. And they do give specific instructions; they do not tell the reader to pass flags of the reader's taste to autogen.sh or the compiler, or to install Visual Studio 2015 instead of the currently instructed 2013. He or she just follows the instructions in order to get one first successful build, without understanding much about building LibreOffice as a beginner. That's my point: I believe there should be instructions to get one successful build. Then, if the newcomer wants to deviate from those instructions after that and make another build with specific flags or use another version of Visual Studio, there would be no guarantee of a successful build and the newcomer would have to read and look around more. But they would know that a failed build was now due to that specific change in specified flags or the change in environment. I just believe the first build should be straight ahead, so the newcomer can check that the initial environment was set up correctly. And I would like to write the instructions to make such a build – if it is possible, which I am not sure it is. I am guessing that following the https://wiki.documentfoundation.org/Development/lode instructions will build one of the three Jenkins builds. Is that true? And if so, which one of them? If it doesn't build one of those, how can the newcomer then know if a failed build was caused by them not setting up the prerequisites correctly?
I had to give up building and debugging LibreOffice a year ago, as the instructions were too unclear. I am currently using version 5.2.5.1 on Windows 10 and the deadlock just happened again: The user interfaces of both LibreOffice and Clipboard Help+Spell suddenly locked while I was typing, and when I killed the Clipboard Help+Spell process, LibreOffice immediately became responsive again. I am not using 5.3.0.1 due to another bug (Bug 105844 – FILESAVE: Very slow saving compared to 5.2.5), so I can't tell whether the problem exists in version 5.3.0.1 too. I can't do any debugging unless someone gives me precise instructions on how to do that, i.e. tells me exactly what to do and what to report when the deadlock happens again. This bug might be related to Bug 103852 - "win32: clipboard deadlock", as also indicated by the See Also field. But Bug 103852 should presumably have been fixed, although not verified, in 5.2.5, so they might be two different bugs.
Dear jhertel, Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
I can try for a while, but I can't do much more than leave LibreOffice running for hours while I do other stuff, and then see if the problem arises by itself. Then I will have to install 5.2.7.2 again, since newer versions of LibreOffice still have the previously mentioned long-standing bug that seriously affects working with encrypted documents (Bug 105844), so I can't use newer versions until that bug has been fixed. At least with this present bug (98002), I have made a workaround program that automatically closes Clipboard Help+Spell whenever I start LibreOffice, so it's kind of bearable now, except I can't use Clipboard Help+Spell when LibreOffice is running. But I'll turn off my little workaround program and try the fresh version of LibreOffice for some hours to see if the bug shows up.
(In reply to jhertel from comment #15) > But I'll turn off my little workaround program and try the fresh version of > LibreOffice for some hours to see if the bug shows up. Please do. Thanks
Now I have had a document open constantly for 5 days in the background while I did other work on the computer, and the bug didn't show up. Sometimes I typed something into the document for a short while, but I didn't outright work on the document, so the test was not realistic. But the deadlock didn't happen at any time, unless it only appears temporarily and then goes away again (i.e., deadlock for a few minutes, waiting for a timeout); I would not notice that happening when the document is just in the background, and I don't use Clipboard Help+Spell all the time, so I likely wouldn't notice if Clipboard Help+Spell hanged temporarily either. So I can neither conclude that the bug is gone, nor that it is still there. I did find out that Bug 105844 is still very much there in the Fresh version, though; saving still takes 5-10 seconds (typically 7) on my fast computer with SSD, which is terribly annoying as I have the good habit of saving whenever there is a pause in my writing, typically after each sentence written. So if the deadlock is in fact gone now, I can now choose between two evils; terribly slow saving or having to close Clipboard Help+Spell every time I start LibreOffice. But I think my current choice is to stick with the Fresh version for a while, especially to further investigate whether the deadlock appears when I actually work on a document for a while.
Hello jhertel, A new major release of LibreOffice is available since this bug was reported. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Dear jhertel, 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
As (1) I am not using LibreOffice very much (due to long-standing bugs like this and the other one I mentioned), and (2) the bug is elusive and can't be replicated just like that, it's difficult to determine whether the bug has been solved. I don't remember seeing the symptoms for quite a while with more recent versions of LibreOffice, but again, I have only used LibreOffice for perhaps one or two hours in total for the past year, and the symptoms appear "out of nowhere" after using LibreOffice for a while. My guess is, though, that the bug has somehow been solved. Or perhaps the author of Clipboard Help+Spell solved the similar bug in his program, so the mutual deadlock can no longer appear. It takes two to deadlock. In any case, I haven't seen the symptoms for a long time, so we could assume that the problem "went away". I can't really find a proper RESOLVED sub-state for cases like this, though. Maybe the closest one is "INSUFFICIENTDATA", as both you and I have insufficient data to tell whether it has been fixed. So I'll go with that one. I assume I can reopen if the symptoms come back.