Bug 93912 - Persistently 100% CPU usage by soffice.bin headless after accessing through SDK
Summary: Persistently 100% CPU usage by soffice.bin headless after accessing through SDK
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: sdk (show other bugs)
Version:
(earliest affected)
5.0.1.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-09-04 06:35 UTC by Richard THIBAULT
Modified: 2017-04-18 16:11 UTC (History)
2 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 Richard THIBAULT 2015-09-04 06:35:10 UTC
We are using soffice headless as document generation engine.

Here is the command line we use to start the server : 

soffice --headless --nologo --nodefault --norestore --nocrashreport --nolockcheck --nofirststartwizard --accept="socket,host=localhost,port=8100;urp;StarOffice.ServiceManager"

After a first document composition using UNO Java SDK on any ODT document (we make some fields replacement, some images replacement, a table modification and a PDF export and then we dispose the ODT document), the soffice.bin goes into a 100% CPU state.
It continues to answer to UNO requests, but it keeps using 100% of a single core.

We are using LibreOffice 5.0.1 RPM distribution on Amazon Linux x64 2015.03
We had the same behaviour if we use the engine OpenOffice 4.0.1 

I don't know if the behaviour is the same on Linux x86.

We are using Xvfb as display manager, since Amazon Linux doesn't provide any window manager integration.

Thank you very much for your help.
Comment 1 Richard THIBAULT 2015-09-04 06:38:36 UTC
I precise that if I use soffice on Windows with the same client SDK generation program, the CPU usage is ok.
Comment 2 Buovjaga 2016-03-21 20:22:27 UTC
You could try getting a cachegrind trace: https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_cachegrind_trace
Note that you need LibO built with --enable-symbols

Here is a master build with --enable-dbgutil which is equal: http://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@70-TDF-dbg/current/

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided further testing information.
Comment 3 Richard THIBAULT 2016-03-22 15:56:12 UTC
Thank you very much for your feed-back.

I tried to execute the libreOffice distribution version located in  http://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@70-TDF-dbg/current/, but it does not start :

The command I launched is :

soffice --headless --nologo --nodefault --norestore --nocrashreport --nolockcheck --nofirststartwizard --accept=socket,host=localhost,port=8200;urp;StarOffice.ServiceManager

Here is the output I got :
bootstap: file:///opt/libreoffice5.2.0.0.alpha/LibreOfficeDev_5.2.0.0.alpha0_Linux_x86-64_archive/program/bootstraprc
user installation: file:///opt/libreoffice5.2.0.0.alpha/LibreOfficeDev_5.2.0.0.alpha0_Linux_x86-64_archive/libreofficedev/4
Generate pipe md5 for 'file:///opt/libreoffice5.2.0.0.alpha/LibreOfficeDev_5.2.0.0.alpha0_Linux_x86-64_archive/libreofficedev/4'
result: /tmp/OSL_PIPE_0_SingleOfficeIPC_a285f3efcbd7415011a6cfa85f5e48a5
Failed to connect to pipe: /tmp/OSL_PIPE_0_SingleOfficeIPC_a285f3efcbd7415011a6cfa85f5e48a5

Is there a problem with this build ?

Regards.
Comment 4 Buovjaga 2016-03-22 17:07:32 UTC
Perhaps.. The only newer debug build currently is this 32-bit one: http://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86@71-TDF-dbg/current/
Comment 5 Xisco Faulí 2016-10-10 11:24:14 UTC Comment hidden (obsolete)
Comment 6 QA Administrators 2016-11-08 12:48:02 UTC Comment hidden (obsolete)
Comment 7 Paolo Benvenuto 2017-02-20 21:45:42 UTC
still present in LibreOffice 5.2.4.2.1 20m0 debian jessie
Comment 8 Richard THIBAULT 2017-04-18 15:54:12 UTC
The problem has been resolved by itself ...
I was on Amazon Linux 2015.09, and I have updated to Amazon Linux version 2017.03, and the problem has gone!
The soffice.bin process has now a normal CPU behavior!

Best regards !
Comment 9 Richard THIBAULT 2017-04-18 15:59:09 UTC
A precision. My exact Linux version is : Linux version 4.1.13-18.26.amzn1.x86_64 (mockbuild@gobi-build-64010) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) )

I confirm that using this version, I don't have this problem anymore.
Comment 10 Buovjaga 2017-04-18 16:11:28 UTC
Thanks! Closing.