Download it now!
Bug 56511 - Server-side file descriptor leak per UNO connection resulting in a segmentation fault
Summary: Server-side file descriptor leak per UNO connection resulting in a segmentati...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: sdk (show other bugs)
Version:
(earliest affected)
3.6.2.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium critical
Assignee: Stephan Bergmann
URL:
Whiteboard: target:4.3.0 target:4.2.1 target:4.1.6
Keywords: regression
Depends on:
Blocks:
 
Reported: 2012-10-29 06:47 UTC by Horst Reiterer
Modified: 2015-12-15 22:23 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Horst Reiterer 2012-10-29 06:47:15 UTC
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.
Comment 1 Bernhard Scholze 2012-10-30 08:27:01 UTC
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
Comment 2 Stephan Bergmann 2012-11-16 16:51:59 UTC
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).
Comment 3 Horst Reiterer 2013-05-16 12:44:52 UTC
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.
Comment 4 Horst Reiterer 2013-06-25 22:08:38 UTC
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.
Comment 5 Joel Madero 2013-12-20 15:28:11 UTC
Requesting advice from developers
Comment 6 Robinson Tryon (qubit) 2014-02-03 14:26:43 UTC
(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!
Comment 7 Commit Notification 2014-02-07 13:38:41 UTC
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.
Comment 8 Commit Notification 2014-02-07 15:06:59 UTC
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.
Comment 9 Stephan Bergmann 2014-02-07 15:48:22 UTC
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.
Comment 10 Commit Notification 2014-02-07 17:01:18 UTC
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.
Comment 11 Robinson Tryon (qubit) 2015-12-15 22:23:49 UTC
Migrating Whiteboard tags to Keywords: (Regression)
[NinjaEdit]