Download it now!
Bug 124798 - Headless Writer conversion to PDF consumes is stuck at 100% CPU usage
Summary: Headless Writer conversion to PDF consumes is stuck at 100% CPU usage
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.2.2.2 release
Hardware: x86-64 (AMD64) All
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, regression
Depends on:
Blocks: Commandline PDF-Export CPU-AT-100%
  Show dependency treegraph
 
Reported: 2019-04-17 14:58 UTC by Nicolas Göddel
Modified: 2019-05-21 14:10 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
ODT file which does not want to be converted to PDF (4.17 MB, application/vnd.oasis.opendocument.text)
2019-04-17 14:59 UTC, Nicolas Göddel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nicolas Göddel 2019-04-17 14:58:06 UTC
Description:
We are developing a software which create ODT files and then uses lowriter to convert the file to PDF.

For some reason this is not working with every document we are giving to writer. It seems to work with some documents but not with others. However, it always works when opening the ODT using the UI and then press the "Export to PDF" button.

Steps to Reproduce:
There are two versions to reproduce this bug:
A) Using convert-to:
1. Save the ODT file stored as attachment to this bug report on your harddrive, say to /tmp/failure.odt
2. Start the following command in the terminal:
lowriter --headless --convert-to pdf:writer_pdf_Export --outdir /tmp /tmp/failure.odt
3. While the process is running look into htop or a similar utility to see that soffice.bin shows 100% CPU usage and never stops to do that.
4. Wait some minutes or longer if you want to, but even after an hour it will not stop. You can kill it now.

B) Using a macro:
1. Save the ODT file stored as attachment to this bug report on your harddrive, say to /tmp/failure.odt
2. Create a new Module in the Standard library, e.g. Module1 and write a simple script to create a PDF:

REM =========================
Sub Main(Optional filename As String)

	Dim storeChanges as Boolean

	If IsMissing(filename) Then
		document = ThisComponent
		filename = ConvertToURL("/tmp/failure.odt")
		storeChanges = False
	Else
		document = StarDesktop.loadComponentFromURL(ConvertToURL(filename), "_blank", 0, Array())
		storeChanges = True
	End If
	
	dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")
	
	'Export to PDF
	dim args1(1) as new com.sun.star.beans.PropertyValue
	args1(0).Name = "URL"
	args1(0).Value = filename + ".pdf"
	args1(1).Name = "FilterName"
	args1(1).Value = "writer_pdf_Export"
	
	msgbox(args1(0).Value)
	
	dispatcher.executeDispatch(document.CurrentController.Frame, ".uno:ExportDirectToPDF", "", 0, args1())
	
	If storeChanges Then
		document.store()
		document.close(True)
	End If

End Sub
REM ==================================
3. Close Writer and every other office process.
4. Call the following command from the terminal:
lowriter --headless "macro:///Standard.Module1.Main(\"/tmp/failure.odt\")"
5. While the process is running look into htop or a similar utility to see that soffice.bin shows 100% CPU usage and never stops to do that.
6. Wait some minutes or longer if you want to, but even after an hour it will not stop. You can kill it now.

Actual Results:
Just 100% CPU usage and no result.

Expected Results:
A nice PDF within seconds.


Reproducible: Always


User Profile Reset: No



Additional Info:
It may have to do with embedded graphics. It seems to work when the attribute svg:height or svg:width of <draw:frame> has a lower value or no value. Maybe there is something going in an infinite loop while layouting these frames which does not go in a loop when using the UI.

Version: 6.2.2.2
Build-ID: 1:6.2.2-0ubuntu0.18.04.1~lo1
CPU-Threads: 8; BS: Linux 4.4; UI-Render: Standard; VCL: gtk3; 
Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE
Calc: threaded
Comment 1 Nicolas Göddel 2019-04-17 14:59:08 UTC
Created attachment 150827 [details]
ODT file which does not want to be converted to PDF
Comment 2 Nicolas Göddel 2019-04-18 08:10:37 UTC
Some extra information: Just stumbled on unoconv. Using unoconv there seems no problem at all. Exporting to PDF works great but not flawlessly. The fields were not updated before exporting.
Comment 3 paulmcquad 2019-05-12 18:58:38 UTC
Hello Nicolas Göddel,

Thank you for reporting the bug. I can confirm that the bug is present in master.

Version: 6.3.0.0.alpha0+
Build ID: 98630a0bd49bd80652145a21e4e0d0ded792b36b
CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: kde5; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-05-04_04:44:35
Locale: en-IE (en_IE.UTF-8); UI-Language: en-US
Calc: threaded
Comment 4 Buovjaga 2019-05-21 14:10:23 UTC
Bibisected with win32-6.3 to range https://gerrit.libreoffice.org/plugins/gitiles/core/+log/b593634d3cfbb2fc8522d99ce1c3f2a11445ea59..bf8c8699f7ed09519db2041e1ec1554097e94ab4

bf8c869 sd: fix comphelper::OInterfaceCompare build breakage by Michael Stahl
5879351 tdf#122607 sw: restore CalcLayout() call in getRendererCount() by Michael Stahl
3d37463 tdf#122607 sw: fix preservation of text frame cache entries by Michael Stahl
31ae750 tdf#122607 sw: remove deleted SwTextFrame's cache entry by Michael Stahl
f6f53f7 tdf#123636 writerfilter: handle deferred breaks on frames by Justin Luth
cc899c6 tdf#101826 ww8import: Fly - don't convert XATTR back and forth by Justin Luth

The document does not have text frames, but it does have images and a section.