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
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?
renaming the profile from 4 to 4-old does not change the problem. Still crashes with bad allocation.
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.
Please try to disable openGL and HW acceleration. Tools - Options -View (bug 108116)
Harware accelleration turned off OpenGL turn off Same result
Probably the same cause as bug 111347; so effectively bug 109253 Possible solution: bug 109253 comment 13 -> install the latest Windows updates for Win7
Same problem with 5.4.1.2 release. All updates to Win 7 Ultimate have been applied.
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
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?
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.
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.
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/
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.
(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.