Download it now!
Bug 125341 - Crash upon exporting a specific document to PDF in Windows 10 version 1809 (not always reproducible) - see Comment 26
Summary: Crash upon exporting a specific document to PDF in Windows 10 version 1809 (n...
Status: RESOLVED NOTOURBUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
6.1.6.3 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: PDF-Export
  Show dependency treegraph
 
Reported: 2019-05-17 13:46 UTC by Jules Renton--Epinette
Modified: 2019-10-05 11:20 UTC (History)
8 users (show)

See Also:
Crash report or crash signature: ["mergedlo.dll"]


Attachments
Document causing a crash when trying to export it as PDF (37.61 KB, application/vnd.oasis.opendocument.text)
2019-05-27 06:47 UTC, Jules Renton--Epinette
Details
1-character document that exhibits the bug. (10.25 KB, application/vnd.oasis.opendocument.text)
2019-09-20 14:38 UTC, Igx
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jules Renton--Epinette 2019-05-17 13:46:59 UTC
Description:
When trying to export an ODT document as a PDF on LibreOffice Writer, the application crashes.
The PDF file is not created, and instead it leaves two files, something like "lu50764ckd.tmp" (which is empty) and a hidden ".~lock.MyDocument.pdf#".

Steps to Reproduce:
1. Click on the "Export as PDF" button in the toolbar then hit "Save", or File->Export... and save as a PDF.
2. Crash.

Actual Results:
LibreOffice crashes and the PDF file is not created, only a ~lock and an empty .tmp file.

Expected Results:
A PDF file is created and LibreOffice Writer remains opened.


Reproducible: Always


User Profile Reset: No


OpenGL enabled: Yes

Additional Info:
Version: 6.1.6.3 (x64)
Build ID: 5896ab1714085361c45cf540f76f60673dd96a72
Threads CPU : 4; OS : Windows 10.0; UI Render : GL; 
Locale : fr-FR (fr_FR); Calc: CL
Comment 1 Aron Budea 2019-05-18 00:22:40 UTC
Does it happen with any file, eg. an empty document, or only with specific ones? If the latter, can you attach it? Does LO attempt to submit a crash report after the crash?
Comment 2 Jules Renton--Epinette 2019-05-27 06:47:33 UTC
Created attachment 151693 [details]
Document causing a crash when trying to export it as PDF

The crash only occurs with this particular document.

Once, before crashing, I got this error message: "The instruction at 0x00007FFBDD99DE0D uses the memory address 0x000001AA0000004E. The memory state cannot be read."

(translated from French. The actual message was "L'instruction à 0x00007FFBDD99DE0D emploie l'adresse mémoire 0x000001AA0000004E. L'état de la mémoire ne peut pas être read.")
Comment 3 Jules Renton--Epinette 2019-05-27 06:49:15 UTC Comment hidden (obsolete)
Comment 4 Xisco Faulí 2019-05-27 10:29:45 UTC
I can't reproduce it in

Version: 6.3.0.0.alpha1+
Build ID: 53325b40b557cc84d8d21c1baa0ef8d3bfc00ab8
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded

nor in

Versión: 6.2.3.2
Id. de compilación: aecc05fe267cc68dde00352a451aa867b3b546ac
Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; VCL: win; 
Configuración regional: es-ES (es_ES); Idioma de IU: es-ES
Calc: threaded

To be certain the reported issue is not
related to corruption in the user profile, could you please reset your
Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and
re-test?

I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' if the issue is still present
Comment 5 Jules Renton--Epinette 2019-05-27 11:14:41 UTC
The issue persists after starting LibreOffice in safe mode and resetting my user profile.
Comment 6 raal 2019-05-27 11:39:57 UTC
No crash with Version: 6.2.0.0.alpha1+
Build ID: a20a2d7e0d28658f2d9089da076961a599833a28
CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win;
Comment 7 Dieter Praas 2019-05-27 12:19:40 UTC
I confirm crash with

Version: 6.3.0.0.alpha1+ (x64)
Build ID: e92dcfdc7bd7b237e0bee26ff226a102d9e8e766
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-05-14_00:00:57
Locale: en-US (de_DE); UI-Language: en-US
Calc: threaded

setting: Export directly as PDF
Comment 8 Xisco Faulí 2019-05-30 12:00:36 UTC Comment hidden (obsolete)
Comment 9 Dieter Praas 2019-05-30 12:58:27 UTC
(In reply to Xisco Faulí from comment #8)

> Hello Dieter,
> What do you mean 'export directly as PDF' ? Using the button in the toolbar ?

File => Export As => Export Direcly as PDF
Comment 10 Xisco Faulí 2019-05-30 13:58:32 UTC Comment hidden (obsolete)
Comment 11 Xisco Faulí 2019-05-30 14:21:02 UTC
I've just updated to

Versión: 6.2.4.2
Id. de compilación: 2412653d852ce75f65fbfa83fb7e7b669a126d64
Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; VCL: win; 
Configuración regional: es-ES (es_ES); Idioma de IU: es-ES
Calc: threaded

and it works fine
Comment 12 Dieter Praas 2019-05-30 15:52:42 UTC
(In reply to Xisco Faulí from comment #10)
> I can't reproduce it here. What happens if you disable OpenGL ?

It also crashes. And it crashes with

Version: 6.2.4.2 (x64)
Build-ID: 2412653d852ce75f65fbfa83fb7e7b669a126d64
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: threaded

to be more precise: LO asks me, where I want to save PDF-file. I choose a folder, press Ok. LO starts savng and crashes after a few seconds.
Comment 13 Dieter Praas 2019-05-30 15:55:19 UTC
Further observation: Jules an I are using Windows 10, while you an Raal are using Windows 6.1. Could this be a reason for the different results?
Comment 14 raal 2019-05-30 18:36:59 UTC
no crash with Version: 6.3.0.0.alpha1+ (x64)
Build ID: 2574ce0f2dc711e71b4799bbd76d5d8b6ec04300
CPU threads: 1; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2019-05-29_22:36:58
Comment 15 Dieter Praas 2019-05-31 08:12:57 UTC
I recognized, that LO finally creates a PDF from that document, but I can't open it. I triedd to attach it, but recieved the message: "The file you are trying to attach is empty, does not exist, or you don't have permission to read it." Indeed, the size is 0kb.
Comment 16 Carlton 2019-08-14 21:52:34 UTC
I've had the same problem. LibreOffice crashes after creating a report, saving to .odt then exporting to .PDF
LibreOffice 6.1 Linux Mint 18.1'Serena'
Comment 17 Dieter Praas 2019-08-19 07:53:49 UTC
*** Bug 126995 has been marked as a duplicate of this bug. ***
Comment 18 Xisco Faulí 2019-09-02 10:41:58 UTC Comment hidden (obsolete)
Comment 19 Dieter Praas 2019-09-03 06:26:39 UTC
(In reply to Xisco Faulí from comment #18)
> @Dieter Pass, Do you reproduce bug 127190 on your side ?

No, I don't.
Comment 20 Timur 2019-09-13 13:15:30 UTC
No crash for me in Windows 7. Due to Comment 16, I tested in Mint 18.3 but also no crash. So that comment remains unclear, is it with this same file. 

So far we have indication it's Windows 10 and I add to title. You who reproduce, please write Windows version. 
And test both with 6.1 where it happened and master that is 6.4+ now. Than please update OS if not, that helped in Bug 126995 when updated to 1903.
Also please try with normal PDF export, but with different options. 
Until then, I set Needinfo.
Comment 21 Timur 2019-09-13 13:32:30 UTC
(In reply to Aron Budea from comment #1)
Does LO attempt to submit a crash report after the crash?
Please write link here if it does.
Comment 22 Igx 2019-09-20 14:38:20 UTC
Created attachment 154325 [details]
1-character document that exhibits the bug.

I also witnessed the same bug, and reduced my document to the single character that caused the probem.
Hope this helps...

How to recreate the bug :
- Open document with Libreoffice 6.3.1 on Windows 10
- Click on the "Direct export to PDF Format" button on main bar
Comment 23 Dieter Praas 2019-09-20 15:14:26 UTC
(In reply to Igx from comment #22)

> How to recreate the bug :
> - Open document with Libreoffice 6.3.1 on Windows 10
> - Click on the "Direct export to PDF Format" button on main bar

Still no crash

Version: 6.3.2.2 (x64)
Build-ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c
CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: threaded

As Timur wrote in comment 21: Doe you recieve a crah report?
Please write link here if it does.
Comment 24 Igx 2019-09-20 15:35:19 UTC
> Still no crash

Gasp :-(

> Version: 6.3.2.2 (x64)
> Build-ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c
> CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; VCL: win; 
> Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
> Calc: threaded

I don't know how you manage to generate this information, but here are the differences with my installation :

- Version is 6.3.1.2
- No OpenGL, , but material acceleration checked
- localization : fr-FR (like the bug submitter himself... maybe that's a clue ?)

> As Timur wrote in comment 21: Doe you recieve a crah report?

Sometimes (not always)

> Please write link here if it does.

crashreport.libreoffice.org/stats/crash_details/a264e087-4383-4906-b2dd-dd1fee603b38
Comment 25 Dieter Praas 2019-09-20 15:46:31 UTC
(In reply to Igx from comment #24)
> I don't know how you manage to generate this information, 

Copy from Help => About LibreOffice
Comment 26 Igx 2019-09-23 07:13:05 UTC
This week-end, I tested this bug on all my machines, and took advantage of this to test before and after LibreOffice upgrade. That resulted in an insane number of tests (38!) out of which I only found 1 new machine that had the bug. Upgrading LibreOffice never changed anything.
Still, I had two similar machines (Windows 10, French version) – one that exhibited the bug, and one that did not. I was trying to find the difference between both (reinstalled LO to be sure I used the same options…) when I had the curiosity to go check what had been said on the bug #126995, which has been marked as a duplicate of this one.
There, the submitter solved the problem himself by upgrading Windows 10 to version 1903.
Checking on my two Windows 10 machines, I realized the working one was in version 1903, whereas the faulty one was still in version 1809. I upgraded to version 1903 (took sooooooo long…), and – bingo – the bug had disappeared.
I decided to wait until Monday to check on my office machine, where the bug appeared first. Its version is 1803.
I don’t know whether I’ll be allowed by the IT to upgrade the Windows version on it (I’ll keep you updated if I can), but I’m pretty sure it would solve the problem.

So, as far as I know, the problem only appears in
- French versions of Windows 10 before 1903
- Documents using the character: ⚠
- During any kind of export to PDF.
If anyone else could test in these conditions, and then upgrade to 1903, it would be helpful.

It does not mean (although it’s highly probable) that the bug is within Windows and not LibreOffice (after all, Microsoft Print to PDF & PDFCreator printers manage to print this character in old version of Windows 10), but it still means that an acceptable workaround has been found (upgrade to Windows 10 version 1903+).

I don’t know how you LibreOffice gurus handle this case, but the bug #126995 has been marked Solved / WorksForMe – although Solved / NotOurBug may be more relevant… I’ll let you change the bug status according to the usual process of this site.
Comment 27 Dieter Praas 2019-09-23 07:33:11 UTC Comment hidden (obsolete)
Comment 28 Dieter Praas 2019-09-23 07:35:16 UTC
Jules, it seems, that Igx found a solution. Can you confirm, that it only happens in Windows 10 1809?

=> NEEDINFO
Comment 29 Jules Renton--Epinette 2019-09-23 08:35:51 UTC
Yeah, I confirm.
Comment 30 Dieter Praas 2019-09-23 08:37:34 UTC
(In reply to Jules Renton--Epinette from comment #29)
> Yeah, I confirm.

So let's close this as RESOLVED NOTOURBUG.

Xisco, please correct this, if I did it wrong.
Comment 31 Timur 2019-10-04 09:54:58 UTC
This may well be LO bug but it's reasonable to expect that anyone who decided to use Windows 10 accepts and applies updates which resolved the issue.
So this could be marked as WontFix but is also acceptable to remain NotOurBug.
And Bug 126995 seems duplicate but never mind.