Bug 111900 - Bad Allocation error on PDF export
Summary: Bad Allocation error on PDF export
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.4.0.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: 2017-08-18 17:07 UTC by Robert McClure
Modified: 2017-09-10 16:56 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Text file that when exported to PDF causes crash (36.43 KB, application/vnd.oasis.opendocument.text)
2017-08-18 17:07 UTC, Robert McClure
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert McClure 2017-08-18 17:07:05 UTC
Created attachment 135647 [details]
Text file that when exported to PDF causes crash

PDF export of simple text causes Bad Allocation crash.

Libreoffice Writer
Version: 5.4.0.3 (x64)
Windows 7 Ultimate
Service Pack 1
AMD FX-6100 3.3G processor
16.0GB memory

file that causes crash is attached
Comment 1 raal 2017-08-18 17:11:55 UTC
I can not confirm with Version: 6.0.0.0.alpha0+
Build ID: b6e32d53ce9c98bfba517c40f53d40e97a091b0e
CPU threads: 4; OS: Windows 6.1; UI render: default; 

For the test, could you rename your LibreOffice directory profile (see https://wiki.documentfoundation.org/UserProfile) and give it a new try?
Comment 2 Robert McClure 2017-08-18 17:48:10 UTC
renaming the profile from 4 to 4-old does not change the problem. Still crashes with bad allocation.
Comment 3 Robert McClure 2017-08-18 17:57:06 UTC
Further experimentation show it crashes on a file that contains just one word "simple" in Liberation Serif 12pt that has never been modified. Unchecking all of the PDF options for output does not fix the problem either.
Comment 4 raal 2017-08-18 18:02:24 UTC
Please try to disable openGL and HW acceleration.
Tools - Options -View

(bug 108116)
Comment 5 Robert McClure 2017-08-18 19:09:04 UTC
Harware accelleration turned off
OpenGL turn off
Same result
Comment 6 Telesto 2017-08-18 20:23:57 UTC
Probably the same cause as bug 111347; so effectively bug 109253 
Possible solution: bug 109253 comment 13 -> install the latest Windows updates for Win7
Comment 7 Robert McClure 2017-09-02 15:35:12 UTC
Same problem with 5.4.1.2 release. All updates to Win 7 Ultimate have been applied.
Comment 8 Buovjaga 2017-09-09 16:35:07 UTC
No crash here either.

Not sure, how possible it is to get a debug trace of a bad allocation, but here are instructions in case you want to try: https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg

Win 10
Version: 5.4.1.2 (x64)
Build ID: ea7cb86e6eeb2bf3a5af73a8f7777ac570321527
CPU threads: 4; OS: Windows 6.19; UI render: default; 
Locale: fi-FI (fi_FI); Calc: group
Comment 9 Robert McClure 2017-09-09 20:12:50 UTC
Installed Windows debugger, but got no analysis because Libreoffice didn't actually crash, but rather produced the error message Bad Alloc. At this point Libreoffice is still running and asking the debugger to analyze produces nothing. If at this point you hit OK, Libreoffice exits normally and the debugger has nothing to do. I suppose an actual crash might be debuggable but the message produced by Libreoffice (Writer) should be able to provide information about what was going on. The implication of the message is that Writer was asking the system for memory and not getting it. That suggests that Writer was asking for a LOT more memory than is available. Without the source code before me, I can do no better than guess what is going on.

Can you suggest a procedure for determining exactly what the system call that produces the Bad Alloc error?
Comment 10 Buovjaga 2017-09-10 13:04:08 UTC
Hmm, maybe you could try procdump.

Here is a Windows build, which has been compiled with debugging features enabled: https://dev-builds.libreoffice.org/daily/master/Win-x86@39/current/
It installs separately from your stable installation.

Here are the procdump instructions (you have to download the procdump utility as well):
https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg#Producing_a_mini_dump

Then just "Ensure your LibreOffice debug build is running" and you can follow the steps.

Maybe before trying the dumping, you could confirm that the error still happens with the debug build.
Comment 11 Robert McClure 2017-09-10 14:48:00 UTC
The debug build suggested was downloaded and installed. This version did NOT produce the error message Bad Alloc, but rather a warning message: Document file 'Untitled%302.pdf' is locked for editing by yourself on a different system since 09.09.2017 13.00
Close document on other system and retry saving or ignore own file locking and save current document;  [three option boxes: Retry Saving - Save - Cancel]
Retry Saving repeats the same warning. Save, however, writes a PDF which is correct.
I did not download the dump as there seems to be no need at this point.
Comment 12 Buovjaga 2017-09-10 15:00:18 UTC
Ok, that sounds encouraging. It might be that something specific to your problem was fixed in the unreleased version.

The locking thing means that there is a hidden lock file in the folder. If it exists, you can see it by configuring the folder view to display hidden files: https://support.microsoft.com/en-us/help/14201/windows-show-hidden-files

The debug builds do sometimes behave differently from normal builds, especially regarding performance. To 100% confirm the fix, you could try a normal daily build:
https://dev-builds.libreoffice.org/daily/master/Win-x86_64@42/current/
Comment 13 Robert McClure 2017-09-10 16:40:10 UTC
Success! The normal daily build seems to work perfectly in writing PDFs. I tried three different files that had previously crashed and they all wrote without a problem. Until the next major release, I plan on using 5.4 for major editing, but when I need to write a PDF, use the 6.0 daily build.
Comment 14 Buovjaga 2017-09-10 16:56:01 UTC
(In reply to Robert McClure from comment #13)
> Success! The normal daily build seems to work perfectly in writing PDFs. I
> tried three different files that had previously crashed and they all wrote
> without a problem. Until the next major release, I plan on using 5.4 for
> major editing, but when I need to write a PDF, use the 6.0 daily build.

Great! Let's close this for now. If the problem comes back at some point, we can always revert the status.