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?

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.")

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

The issue persists after starting LibreOffice in safe mode and resetting my user profile.

No crash with Version: 6.2.0.0.alpha1+
Build ID: a20a2d7e0d28658f2d9089da076961a599833a28
CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win;

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

(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

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

(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.

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?

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

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.

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'

*** Bug 126995 has been marked as a duplicate of this bug. ***

(In reply to Xisco Faulí from comment #18)
> @Dieter Pass, Do you reproduce bug 127190 on your side ?

No, I don't.

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.

(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.

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

(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.

> 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

(In reply to Igx from comment #24)
> I don't know how you manage to generate this information, 

Copy from Help => About LibreOffice

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.

Jules, it seems, that Igx found a solution. Can you confirm, that it only happens in Windows 10 1809?

=> NEEDINFO

Yeah, I confirm.

(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.

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.