I was hoping that this bug got resolved in LibreOffice and since it still appears in 3.3.0 release I decided to re-file the bug in LibreOffice BugTracker (not sure if bugs from OpenOffice.org are investigated automatically). This bug reflects OOo bug ID 113476: <http://qa.openoffice.org/issues/show_bug.cgi?id=113476> The problem has been described on the forums already. See here: <http://user.services.openoffice.org/en/forum/viewtopic.php?f=6&t=3472> and here: <http://user.services.openoffice.org/en/forum/viewtopic.php?f=15&t=28564> Always when multiple documents (no matter if spreadsheet or word processor files) are selected, then right-clicked and "print" is chosen then only one document is printed. The Windows task manager will show then as many soffice.bin and soffice.exe processes as documents selected. For example selecting 3 documents and trying to print them will open 6 processes (3x soffice.bin and 3x soffice.exe). All hanging indefinitely. There is no LibreOffice window shown at all and processes seem to refuse shutdown signals when the user tries to log off so even logoff and shutdown is blocked. Users not familiar with the task manager will be unable to close down all processes manually in order to be able to continue working. While in this state (any soffice.bin and/or soffice.exe process running) it is impossible to open up any other LibreOffice application. This is especially annoying if the user clicked many documents (e.g. clicking 30 documents will create 60 processes which have to be killed individually via task manager). How to reproduce: 1. Create any ODF document 2. Create two copies of the document 3. Select all three ODF documents 4. Right-click the documents selected and chose "print" from the context-menu 5. Open Task Manager to see 6 soffice.bin/soffice.exe processes running I guess it might be related to the "instance detection" feature of LibreOffice but I was unable to disable it (allowing multiple instances). Work-around: No clean work-around known to me. I was trying to create a send-to script called "print in OOo.cmd" which passes all parameters to "soffice.exe -p %*". Unfortunately then a limit of Microsoft applies which limits the number of arguments to 20. So printing more than 20 documents in one batch is impossible (my customer wants to print about 35). Moreover if one already tried the right-click->print action then even the send-to trick will not work any more due to already blocking soffice.bin/soffice.exe processes. Asking an inexperienced user to reboot will not work either since the PC will hang at reboot :-( so the only way is to ask for a system reset which is dangerous to do without clean shutdown. I am still able to reproduce the issue in LibreOffice 3.3.0 release on Windows XP x86, Vista x86 and Windows 7 x64.
this seems completely bonkers, any idea Tor
As the discussion on OOo bugtracker already indicate I think it might be related to some locking and concurrency race-condition within the framework. So during startup somehow the processes block each other. So the first one sometimes finishes printing the job but the others will just hang. When starting to kill some soffice.bin processes sometimes you might hit the right process and therefore unblock the next soffice.bin process in the queue allowing it to print too. Well, maybe somebody might be able to track it down to the code. The instructions I've provided allow me to reproduce the problem on any system I've tried it and it's very simple to do.
Still [Reproducible] with WIRTER and "LibreOffice 3.4.0 – WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:12)]" I successfully printed 4 very simple CALC documents from a WIN Explorer selection. So the problem might be limited to WRITER? I modified Status to Assigned due to facts.
My mistake! Success or fail does not depend on application, but on test conditions. Print will fail when I start without running LibO, but will be successful when LibO Start Center has been opened before.
[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
In 3.5.0 problems still exist?
Just tested on LibreOffice 3.5: - Crated 3 ODT documents - Selected all of them - Right-Click, Print Now I have 3 soffice.bin and 3 soffice.exe processes hanging in my Task manager. So yes, issue is still there.
Thanks for additional testing
I have had to remove LibreOffice 3.5.3 and revert to OpenOffice because of this problem. Not being able to print multiple documents from Windows Explorer is a deal breaker in my organization.
Inherited from OOo. I wonder whether "Bug 42673 - With disconnected network printers, Calc hangs opening some files waiting on the Windows print spooler " might be related. @Kevin <http://wiki.documentfoundation.org/BugReport_Details#Version> What do you think how your comment will help to fix the bug? @sasha Did you test with Linux? Although all comments seem to show that it's WIN only we should have tested that. @Tor: Can you help with some debugging?
On Linux no "Print" option in context menu. It is ok that no "Print" option. At least for KDE.
> On Linux no "Print" option in context menu. Yes, can't find that in Ubuntu, too. @Roman: Is that option known on Mac? And if yes, what's your test result?
(In reply to comment #12) > @Roman: > Is that option known on Mac? And if yes, what's your test result? At least with MacOS 10.6.8, which I still use, there is no 'Print' option in the context menu which appears when I control-click (= right-click) on any LibreOffice file in the Finder (the Finder is the MacOS equivalent to the Windows Explorer). But there is a 'Print' item in the Finder's global 'File' menu. This 'Print' item is enabled as soon as you select one or more document(s) in the Finder, so I would expect this menu item to do exactly what the 'Print' option in the context menu does on Windows. But if I select one ore more .odt document(s) in the Finder and select 'Print' from the 'File' menu, the only thing that happens is that LibreOffice comes to the front (if it is running) or is started (if it isn't running). No file is opened, no Print dialog appears, regardless whether I select 1 or 2 or 3 ... .odt file(s). With other applications, this 'Print' command from the Finder works fine, so I suspect that there is just another LibreOffice bug, but Mac-specific: the print event sent from the Finder (or the OS?) to LibreOffice is not handled at all. IMHO this is a separate issue. Maybe I should open another bug report for it ... will search if there is already a report for this issue.
> IMHO this is a separate issue. Maybe I should open another bug report for it > ... will search if there is already a report for this issue. I believe the Mac problem might have the same roots, but I would prefer a separate bug for now.
I don't think the issue on Mac has the same roots. On Mac LO seems not to do anything when selecting print from finder. Not even when only a single document is selected. On Windows there seem to be some "deadlock" issue between multiple instances started at the same time since one could see multiple soffice.bin/soffice.exe processes running which seem to block each other. On Windows this issue here only appears if multiple LO processes are started at the same time. LO prints just fine from context menu if only one single document is selected at a time. Maybe it would be possible to cause the same issue on Linux or Mac via a script which launches multiple LO instances with command-line arguments to load a document and print it immediately. It might be just a timing issue which causes some deadlock during detection if there is another instance running. Maybe LO tries to detect during document open whether there is already an instance or whether a new one should be launched. If the first instance is busy or not fully loaded it might cause a "split brain" situation where multiple instances which should not be launched in parallel exist and block each other. Although this is just wild guessing as I don't know the LO code yet but I've seen similar issues in other applications (also ones developed by myself). So I agree that the Mac issue should be filed as an independent report (incomplete finder integration, direct printing not working). Maybe it's just about finder integration to supply correct parameters to LO when it's launched by finder.
@Rainer Bielefeld If it's inherited from OpenOffice, it wasn't inherited from the new 3.4.0 version because that version of OpenOffice (thankfully) prints multiple documents from the file Explorer just fine. Additionally, I have tested this on Windows XP Pro (32 bit) and Windows 7 Pro (64bit). Same error. After trying it many times, on both versions of Windows, it will occasionally print just one document, when multiple documents have been selected in Windows Explorer and printed from there. I have no idea why it will print just one document sometimes and hang on the others, while other times, it will just hang and print none of them. I don't know if this matters, but I've tried printing between two and eight documents.
(In reply to comment #14) > > IMHO this is a separate issue. Maybe I should open another bug report for it > > ... will search if there is already a report for this issue. > > I believe the Mac problem might have the same roots, but I would prefer a > separate bug for now. I can not find an existing bug report for this special MacOS X issue, therefore I have filed a new one: bug 49827 - "Incomplete MacOS Finder integration: direct printing not working" (thanks to Rainer Meier, comment #15, for the suggested summary!). If anyone reading this (Rainer Maier?) could confirm this special MacOS issue or make additional comments on it, this would be very welcome! Please comment on the report for bug 49827, not here.
I have tried to debug this bug. As far as I can tell, the problem lies with the code, that tries to connect to another running instance of soffice with a pipe. If two processes are started at the same time, both will connect to the same pipe and wait for an answer from the other process. Since there is no timeout, they will wait indefinitely. Every process started after that, will hang also. The same problem will occasionally happen on Linux, too. It's just difficult to reproduce.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4ce2602befd59e69264d8e4ced8730b40c2b947c Related fdo#33484: Terminate OfficeIPCThread by closing the accepting pipe 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.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6527b8a135c20e223a6fcf7c49835205a99ff02a&g=libreoffice-4-0 Related fdo#33484: Terminate OfficeIPCThread by closing the accepting pipe It will be available in LibreOffice 4.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 downloaded master~2012-12-18_08.36.19_LibO-Dev_4.1.0.0.alpha0_Win_x86_install_en-US.msi from http://dev-builds.libreoffice.org/daily/master/Win-x86@6/2012-12-18_08.36.19/ and tested under Win7: Selecting several (eight) odt-files right-click -> Print There's still one soffice.bin and one soffice.exe per selected document, but they aren't blocking, but are completed one after the other, leaving 8 printjobs in the queue and no running soffice-process in the task manager. It's also possible to open an swriter-window while the other documents are printed.
Sounds like Stephan fixed the deadlock (nice work: thanks), Ulkitz confirms it works, and I'll close the bug - please do re-open it if the problem continues with 4.0 beta2 and later.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c99b59c842167a3151d760bf424b4df7491aa101&h=libreoffice-3-6 Related fdo#33484: Terminate OfficeIPCThread by closing the accepting pipe It will be available in LibreOffice 3.6.6. 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.
Upto and including 4.04.2, printing multiple documents works in Windows 7, but does not work in Windows 8.
@Mark Ellse I suggest to open a separate bug report since this seems a new issue and limited to a specific O/S.
I'm closing this bug report. I created a new report about Win8 issue here: https://bugs.freedesktop.org/show_bug.cgi?id=66919