With LibreOffice 3.6, the server-side leaks one file descriptor per UNO connection. As soon as the process hits the process file descriptor limit, the leak results in a segmentation fault. The behavior can be reproduced with the SimpleBootstrap_cpp sample from the SDK. Executing the following command line results in a new file descriptor (UNIX domain socket in this case) that is not closed as a result of a client disconnect. With 3.5, this leak does not exist. make SimpleBootstrap_cpp.run lsof |grep soffice |grep unix soffice.b 21355 root 106u unix 0xffff8800121789c0 0t0 175533617 /tmp/OSL_PIPE_0_uno8144101731931881471711676210311892102186 soffice.b 21355 root 109u unix 0xffff8800121786c0 0t0 175534325 /tmp/OSL_PIPE_0_uno14212312385238112349061101221822759490 soffice.b 21355 root 112u unix 0xffff8800121783c0 0t0 175534820 /tmp/OSL_PIPE_0_uno164254124824523314314123319913623117099183168 soffice.b 21355 root 115u unix 0xffff8800121780c0 0t0 175535743 /tmp/OSL_PIPE_0_uno1831181191871451201971802186036181212243198 As a result of this leak, production use of LibreOffice 3.6 as an UNO server is out of the question. A workaround is to re-trigger an environment on the client side, interestingly this workaround is only effective in non-SMP environments.
In our continous integration environment the bug occurs already with version 3.5.5. No problems are reported with version 3.5.4. A related checkin prior to the Tag 3.5.5.1 (3.5.5-rc1) might be http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=c4b4ab993b93e57de816d2ca47b0e1be8e24eaab&ss=1
Are you sure that the SimpleBootstrap scenario ever worked differently? What happens is that each SimpleBootstrap_cpp.run invokes an soffice process with an --accept=pipe,name=unoXXX;urp; argument, where XXX is unique for each invocation. If an soffice instance is already running in the background (which I understand it is in your scenario), the newly invoked soffice process passes its --accept argument to the pre-existing instances and quits. Now, the pre-existing soffice instance dutifully opens all the different unoXXX pipes and keeps accepting on them even after the initial client that connected on each one has gone. At least this latter part is by design. The overall (leaking) outcome can indeed be considered surprising, though. The uno executable already knows a "singleaccept" mode, where it accepts only a single connection on an acceptor and then terminates. Something similar would probably be wanted here, like an additional "singleaccept" parameter in those --accept arguments passed from SimpleBootstrap, so that those acceptors would be terminated by the pre-existing soffice instance once the original client has connected. However, using SimpleBootstrap might not be the best solution in your scenario. It is probably better to start the initial soffice with a well-known --accept name and let the clients connect to that well-known name (e.g., via com.sun.star.bridge.UnoUrlResolver).
Thanks for your input, Stephan. I'm positive the file descriptor leak did not exist before. We're using a socket-based UNO connection, I'm afraid the workaround of naming the connection endpoint does not apply in that case. I can reproduce the leak using the DocumentLoader sample provided in the SDK. After adding a missing dispose of the loaded document returned by loadComponentfromURL, one socket leaked by UNO on the server-side per execution remains: make DocumentLoader.run ll /proc/17114/fd|grep socket # ... lrwx------. 1 root root 64 May 16 14:27 91 -> socket:[341977618] lrwx------. 1 root root 64 May 16 14:34 910 -> socket:[341995066] lrwx------. 1 root root 64 May 16 14:34 911 -> socket:[341995118] lrwx------. 1 root root 64 May 16 14:39 912 -> socket:[341995166] lrwx------. 1 root root 64 May 16 14:34 913 -> socket:[341995260] lrwx------. 1 root root 64 May 16 14:34 914 -> socket:[341995308] # ... I started LibreOffice as follows: /opt/libreoffice4.0/program/soffice --nofirststartwizard --nologo --headless --norestore --invisible "--accept=socket,host=localhost,port=2083,tcpNoDelay=1;urp;" Please look into it. IMHO, this is a serious issue for anyone who uses LibreOffice via UNO. For now, we worked around the issue by restarting the instance periodically.
Any news on this issue? Based on the instructions in my previous comment, the problem can be reproduced on Linux platforms. Applications using LibreOffice to convert documents via UNO are affected by this file descriptor leak. While there are ways to work around the leak (by restarting the process on a regular basis), a fix would be much appreciated to restore stability in the UNO case. Please let me know if there's anything else I can do to help.
Requesting advice from developers
(In reply to comment #3) > Thanks for your input, Stephan. I'm positive the file descriptor leak did > not exist before. Whiteboard: PossibleRegression Stephan - Please take another look at this bug and let us know if 1) You can reproduce the behavior 2) Whether the behavior is a bug or not Thanks!
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f6245d5bcb18dff2721d5975cd84711559cefe65 fdo#56511 Don't unduly delay Bridge termination 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-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5e161e9ee63377679fc57f33a216ca4707276700&h=libreoffice-4-2 fdo#56511 Don't unduly delay Bridge termination It will be available in LibreOffice 4.2.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.
So SimpleBootstrap/multiple --accept was indeed a red herring, and the problem was with timely destruction of binaryurp Bridge instances. Sorry this issue somehow fell though the cracks multiple times.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2ed67ffacb14c3e33f91f9f1e78f553397beca38&h=libreoffice-4-1 fdo#56511 Don't unduly delay Bridge termination It will be available in LibreOffice 4.1.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.
Migrating Whiteboard tags to Keywords: (Regression) [NinjaEdit]