Bug 136972 - LibreOffice running in server mode forever, taking 100% CPU
Summary: LibreOffice running in server mode forever, taking 100% CPU
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: sdk (show other bugs)
Version:
(earliest affected)
7.0.1.2 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-09-23 09:54 UTC by Gaëtan Delannay
Modified: 2022-03-15 03:56 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Example of ODT file sent to LO via UNO in order to be converted to PDF (42.16 KB, application/vnd.oasis.opendocument.text)
2020-09-23 10:09 UTC, Gaëtan Delannay
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gaëtan Delannay 2020-09-23 09:54:09 UTC
Description:
When using LibreOffice in server mode, asking him, via UNO (Python 3), to convert a ODT file into PDF, with some ODT documents, LibreOffice never produces the resulting PDF file, never returns any error message but continues to run forever, consuming 100% of available CPU.

Steps to Reproduce:
This is clearly HARD to reproduce:
- it requires an application server to run (Plone or Appy);
- LO running in server mode;
- ask, from the UI, to render a document in PDF format;
- the Appy framework is used behing the scenes, produces an ODT file from a document template, itself being an ODT file (see http://appyframework.org/pod.html), and asks LibreOffice to convert it to PDF.

Moreover, if I try to reproduce it on a DEV environment, it works. It happens only on a production server, on heavy load.

Actual Results:
LO runs forevere, and takes 100% CPU

Expected Results:
LO produces the requested PDF file or a clear error message via the UNO bridge.


Reproducible: Sometimes


User Profile Reset: No



Additional Info:
We are a community of developers and companies using the Appy framework and LibreOffice in server mode to produce millions of documents per year, on hundreds of Appy-powered application servers.

This bug is really blocking for us and occurs at least since LibreOffice 6.0 through LibreOffice 7.0.1.2 (last tested version).

We would be very grateful if you have any idea of what happens here. We have no control on the LO server component, it is for us a black box, without any log or error message, running at 100% CPU.

Thanks a lot, LO is a killer app!

Server config is:
Ubuntu 18.04 LTS
With this PPA enabled:
deb http://ppa.launchpad.net/libreoffice/ppa/ubuntu bionic main
Last soffice version: LibreOffice 7.0.1.2 00(Build:2)
Comment 1 Gaëtan Delannay 2020-09-23 10:09:37 UTC
Created attachment 165791 [details]
Example of ODT file sent to LO via UNO in order to be converted to PDF

This is one of the files sent to LO that produces the bug.

But:
- if you try to convert it to PDF via the standard LO UI, it works
- most of the time, if you try to ask LO to produce it in PDF via UNO, it also works.

The problem occurs on heavy loaded production servers.

I've nevertheless uploaded this file: maybe could you check if the inner files content.xml or styles.xml, which have been generated by appy.pod, contain some singularities or strange constructs?

Thanks a lot.
Comment 2 Gaëtan Delannay 2020-09-23 11:05:48 UTC
I have been able to reproduce the problem.

When calling LO in server mode, with LibreOffice 6.0.x, when asking him to convert big documents (several hundreds of pages) to PDF, sometimes, the resulting PDF was truncated: the last pages were missing from it.

For that reason, in appy/pod/converter.py, just after loading the ODT document to convert in LO, I have added these commands, in a trial to force LO to open it "until the end of the document":

viewCursor.jumpToLastPage()
viewCursor.jumpToEndOfPage()

With LO starting from 6.2 or 6.3, the problem of truncated PDF files has disappeared, but I have kept this code.

These commands cause LO to enter into an infinite loop and consume 100% of CPU.

The bug can be reproduced with the attached file, if you launch LO in server mode and WITHOUT the UI. If the UI is there, the bug does not occur.

The example below is produced with the Appy framework (pip3 install appy), version 1.0.3:

If you launch LO 7 in server mode, but with the UI, via this command:

soffice "--accept=socket,host=0.0.0.0,port=2002;urp;"

And you try to call LO for converting the attached file to PDF, it will work:

python3 /home/gdy999/projets/appy/pod/converter.py /home/gdy999/test1.odt pdf

If you launch LO 7 in server mode, but without the UI, via this command:
soffice --invisible --headless "--accept=socket,host=localhost,port=2002;urp;"&

And you try to call LO for converting the attached file to PDF, LO will never return and use 100% CPU.

python3 /home/gdy999/projets/appy/pod/converter.py /home/gdy999/test1.odt pdf


In the next version of Appy, I will not call these methods anymore (jumpToLastPage, jumpToEndOfPage), but I guess it would be interesting for you to fix this behaviour.

Thanks for your attention

Best regards
Gaetan Delannay
Appy framework developer.
Comment 3 Roman Kuznetsov 2021-08-15 18:51:29 UTC
Please try download, install and use for your case LibreOffice from an official site instead PPA (please select 7.1.5 version):

https://libreoffice.org/download

and give us a some feedback. Thank you
Comment 4 QA Administrators 2022-02-12 03:37:47 UTC Comment hidden (obsolete)
Comment 5 QA Administrators 2022-03-15 03:56:29 UTC
Dear Gaëtan Delannay,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp