This bug was already reported by me for OpenOffice version 2.4 and 3.0 with the build-in error reporter. Unfortunately nothing happened except the automatic generated answer mail: "Thank you for sending the error report generated by the OpenOffice.org error report tool." Is LibreOffice/OpenOffice not designed for heavy load? How to reproduce the bug: - Create a document A3 landscape with lots of scanned images or documents like this one: http://www.library.ucla.edu/yrl/reference/maps/blaeu/paderbornensis.jpg (To get lots of files for this test case don't copy files. The PDF exporter seems to have a deduplication function.) - Call File->Export as PDF... -> (The settings are not important, but on the first tab I choosed 'All', JPG-compression 90%, PDF/A-1a. The other tabs are left to default. ) Click 'Export'. => The export starts. The progress bar is visible and starts to grow. When the output after 13 minutes has reached more or less 50% the Writer suddenly disappears without saying 'Good by'. To reproduce the bug it's important that the output file will exceed 500MB on a Windows system respectively 600MB on Open Suse Linux. (For OpenOffice, With LibreOffice I couldn't validate the size because I didn't found the temporary PDF output.) This crash takes always place. The bug is reproducible! Testing conditions/Platform: - Windows Vista 64-bit with latest SP and patches, Current Open Suse Linux 64-bit with latest patches - LibreOffice 3.3 RC2 (LibreOffice 3.3.0, OOO330m18 (Build:4), tag libreoffice-3.3.0.2) - AMD dual core CPU, AMD/ATI Graphics card, 6GB Memory. (Dual boot system, no virtual machines) I started strace like it is described on http://wiki.documentfoundation.org/BugReport "How to get strace log (on Linux) If the 32-bit LibreOffice is running on 64-bit system..." The call failed: Internet@Knuffi:/opt/libreoffice/program> strace32 -o /tmp/Bugreports/LibreOffice/PDFExportCrash/strace32.log -f -tt -s 512 ./soffice.bin ./soffice.bin: error while loading shared libraries: libuno_sal.so.3: cannot open shared object file: No such file or directory I removed -f and -tt parameters then it worked. See strace32.log in appended files. With the standard call "strace -o /tmp/strace.log -f -tt -s 512 libreoffice" strace produced a 130MB log file which can be reduced to a 50MB zip file. But that's still to big to upload it. Command-line output first try with strace: M@Knuffi:~> strace -o /tmp/Bugreports/LibreOffice/strace.log -f -tt -s 512 libreoffice terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc /opt/libreoffice/program/soffice: Zeile 167: 4300 Der Wecker klingelt "$sd_prog/$sd_binary" "$@" M@Knuffi:~> Second try with other user account: Internet@Knuffi:~> strace -o /tmp/Bugreports/LibreOffice/PDFExportCrash/strace.log -f -tt -a 512 libreoffice terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc soffice.bin: Fatal IO error: client killed Internet@Knuffi:~> I assume that the strace log doesn't contain sufficient information to find the bug. So I installed valgrind. valgrind --tool=memcheck --num-callers=128 --trace-children=yes ./soffice.bin 2>&1 | tee /tmp/valgrind.log (as it is recommended on http://wiki.documentfoundation.org/BugReport ) For the output of this session see appended file valgrind.log.zip. Because it reported uninitialised values and possible memory leaks I rerun it with the parameters which are recommended by the log output. See appended files valgrind_full_Part1.log.zip and valgrind_full_Part2.log.zip. The possible memory leak starts with ==11231== 1 bytes in 1 blocks are possibly lost in loss record 40 of 36,268 and seems to increase to this values before the crash happened: ==11231== 585,101,284 bytes in 7 blocks are possibly lost in loss record 36,268 of 36,268 If you need any further information or help to analyze this bug, please don't hesitate to contact me! Thank you. btw. I couldn't find the debug files for LibreOffice 3.3.0 RC2.
Created attachment 41557 [details] short strace log file
Created attachment 41558 [details] short version of valgrind log without memory leak analysis
Created attachment 41559 [details] full valgrind log (Part 1)
Created attachment 41560 [details] full valgrind log (Part 2)
The retest of this bug with version 3.4 didn't reveal any changes. The writer crashed while 20% of the PDF export was done. If you need a remote debug session to analyze this bug don't hesitate to contact me!
*** Bug 39411 has been marked as a duplicate of this bug. ***
I don't think Bug 39411 is a duplicate: 1. This bug is reporting for a 64-bit system. In my case, a 32-bit LibO is used on a 32-bit OS. (In fact two different PCs are using two different flavors of Windows: XP and 7; and both PCs have exactly the same problem. 2. While this bug describes an outright crash (LibO vanishes without warning or error box), my bug highlights that the LibO process keeps running, and keeps grabbing more and more private bytes (the curve is linear and rising). I aborted the operation at 700+ MB, but it was NOT crashing on its own. Visually, the LibO interface is visible, and shows a hourglass. Therefore, I request that these bugs should not be marked as duplicates.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Retest with 2 versions on same old Vista 64-bit: - LibO_3.4.5rc1_Win_x86_install_multi.exe - LibO-Dev_3.5.0beta2_Win_x86_install_multi.msi The bug is still there and it is 100% reliable. It crashes 3-5 minutes after starting the PDF export. (It seems that since release 3.4.4 the time to crash has shortened.) BTW. The last successful PDF export of this document happened in April 2008. Entry in Windows event log: Problemereignisname: APPCRASH Anwendungsname: soffice.bin Anwendungsversion: 3.4.501.500 Anwendungszeitstempel: 4ee921dd Fehlermodulname: configmgr.uno.dll Fehlermodulversion: 3.4.501.500 Fehlermodulzeitstempel: 4ef5cd79 Ausnahmecode: c0000005 Ausnahmeoffset: 00006546 Betriebsystemversion: 6.0.6002.2.2.0.256.6 Gebietsschema-ID: 1031 Zusatzinformation 1: 08fa Zusatzinformation 2: a032220f9006be4c1ee58cb014cc2214 Zusatzinformation 3: ce4d Zusatzinformation 4: 40a45207b9038a0724dace89f1f9f440 Lesen Sie unsere Datenschutzrichtlinie: http://go.microsoft.com/fwlink/?linkid=50163&clcid=0x0407
(In reply to comment #0) > This bug was already reported by me for OpenOffice version 2.4 and 3.0 with > the build-in error reporter. > How to reproduce the bug: > - Create a document A3 landscape with lots of scanned images or documents like > this one: > http://www.library.ucla.edu/yrl/reference/maps/blaeu/paderbornensis.jpg > [...] > To reproduce the bug it's important that the output file will exceed 500MB on a > Windows system respectively 600MB on Open Suse Linux. (For OpenOffice, With > LibreOffice I couldn't validate the size because I didn't found the temporary > PDF output.) thanks Friedrich for your detailed report! Any change that you have an idea of e.g. anumber of pages that is possible, or the max file size? Cor
Hi Cor, here is the retest with version 3.5 on Vista 64: (ODT document size is still 79KB. 241 JPG files are linked whit that doc and occupy about 1GB space on hard disk.) Time to crash 1:20 min. The size of the temp file (lu1t4cs.tmp) is 178.7 MB. /Friedrich
I can make this happen with a one-character file. The character is an upside-down delta from the "symbols" font. It is called a "del" by mathematicians. I do something funky to it: I highlight the character and convert it to Times New Roman. The del remains there (even though there is no such special character listed in Times New Roman), but I can type after it without my font becoming "symbols". Anyway, I will attach the document if I can figure out how.
Created attachment 58832 [details] Simple file that causes crash on PDF export This is the one-character .odt document that causes Writer to crash when exporting to PDF. The character is an upside-down delta from "Symbols" font that I changed to "Times New Roman".
I should add that I am running LibreOffice 3.5.1 under Windows 7 /64-bit. I don't think this happened in LibreOffice 3.4, but I'm not certain.
(In reply to comment #13) > Created attachment 58832 [details] > Simple file that causes crash on PDF export Also this file exports fine for me. On Linux X86 and Win7 32Bits, however
-- This is a Writer problem, therefore changed 'Component' to 'Writer'. -- If the problem was already present in OOo 2.x/3.0, we use the oldest LibreOffice version available.
(In reply to comment #15) > (In reply to comment #13) > > Created attachment 58832 [details] > > Simple file that causes crash on PDF export > > Also this file exports fine for me. > On Linux X86 and Win7 32Bits, however On pc Debian x86-64, I don't reproduce the problem with master (future 3.6) updated today or with 3.5 branch updated today.
Having had a recent issue on LO 3.4.5 after upgrading from 3.3, and discussed on the mailing list under subject titled `[libreoffice-users] pdf creation issue on a single file?', I have been able to continue using the `Export to PDF' function. It would seem that if there are any print ranges in the document only the page with such print range will export to PDF. Clearing the print ranges re-enabled the creation of the PDF document, at least in my case, YMMV.
(In reply to comment #18) > It would seem that if there are any print ranges in the document only the page > with such print range will export to PDF. Clearing the print ranges re-enabled > the creation of the PDF document, at least in my case, YMMV. Hello Hylton Conacher, this is a very valuable observation. But it seems to be a new issue about PDF export, and distinct from the present issue. Could you please create a new bug report for the problem mentioned by you (see quotation above)? This would be very helpful! Thank you very much in advance!
SRS, Friedrich: do you still reproduce the problem with latest 3.5.X or 3.6.X version with brand new LO profile if needed (see http://wiki.documentfoundation.org/UserProfile)?
The bug is still active. I retested it with the latest release 3.6.2 on Windows Vista 64-Bit. (After deinstalling the old version I removed the ancient remains manually from the "Program Files (x86)" directory and reinstalled the following two packages: LibO_3.6.2_Win_x86_install_multi.msi, LibO_3.6.2_Win_x86_helppack_de.msi.)
(In reply to comment #21) > The bug is still active. I retested it with the latest release 3.6.2 on > Windows Vista 64-Bit. > (After deinstalling the old version I removed the ancient remains manually > from the "Program Files (x86)" directory and reinstalled the following two > packages: LibO_3.6.2_Win_x86_install_multi.msi, > LibO_3.6.2_Win_x86_helppack_de.msi.) Did you try to rename your LO profile (see http://wiki.documentfoundation.org/UserProfile)?
No Feedback since months, so put it WFM Friedrich: if you reproduce the crash with last LO version (3.6.4) with a brand new LO directory profile (see my previous comment), don't hesitate to reopen this tracker.
Retested it with LibreOffice_4.0.0_Win_x86.msi on Vista 64. I renamed the settings directory AppData/Roaming/LibreOffice/ before installing the package. The bug is still aktive! No changes.
I've also been experiencing this problem for a long time. Version 4.0.2RC2 still exhibits this issue.
Friedrich/David: could you attach the odt file so we can try to reproduce?
Producing a document that will cause it to crash will be difficult to do. If there is a file that will always cause it to crash it's been my experience that something is wrong with the file. Like once I had a document where something strange had happened to the paragraph settings. Clearing all formatting and resetting it to use the defaults of the paragraph style it was set for fixed the problem. In the case of this bug though, it is a matter that seems to be more affected by large documents. It is random and I've experienced it ever since OpenOffice introduce the Export to PDF feature. To me it seems like some sort of memory leak. The problem seems to happen usually after a document was being edited. I've learned to save my document every time before I export to PDF to avoid data loss. I don't use this feature real frequently but I would guess that it will crash about every third or fourth time I've been editing a document and then try to export it to PDF. Usually when I re-open and export it right away before any editing it will do it without crashing.
I have exactly one file which crashes _every_ time while exporting to PDF. Unfortunately this document is more or less 1 GB in size (244 JPGs linked in). Last time when I tried to upload a sample the upload limit was 1 MB. Last time I tested it at work and attached Microsoft Visual Studio 2010 to soffice.bin while it had crashed. It revealed that the crash had taken place in Microsoft mem.dll (in an unlock function ?). I downloaded the source but it had no effect because it didn't contain any debug files. (Error text see below) I retried it with WinDebug. It reported an exception in sal3.dll. (Please see appended file "WinDebugOutput.txt") Please supply the community with debug files! See also comment from Andreas Timar underneath the video on http://www.youtube.com/watch?v=fppBTs215yc #ifdef _M_IX86 #pragma optimize("y",on) #endif /* _M_IX86 */ /*** *_lockerr_exit() - Write error message and die * *Purpose: * Attempt to write out the unexpected lock error message, then terminate * the program by a direct API call. This function is used in place of * amsg_exit(_RT_LOCK) when it is judged unsafe to allow further lock * or unlock calls. * *Entry: * *Exit: * *Exceptions: * *******************************************************************************/ void __cdecl _lockerr_exit ( char *msg ) { FatalAppExit(0, msg); /* Die with message box */ __crtExitProcess(255); /* Just die */ }
Created attachment 76561 [details] WinDebug output (created without debug infos)
Michael: by taking a quick look to the bt, we can see this: sal3!osl_incrementInterlockedCount+0x1b: 56b68684 f00fc101 lock xadd dword ptr [ecx],eax ds:002b:00000000=???????? 0:000:x86> g and opengrok shows this (http://opengrok.libreoffice.org/xref/core/sal/osl/w32/interlck.c#63) 63 #else 64 #pragma warning(disable: 4035) 65 { 66 __asm 67 { 68 mov ecx, pCount 69 mov eax, 1 70 mov edx, osl_isSingleCPU 71 cmp edx, 0 72 je is_not_single 73 xadd dword ptr [ecx],eax 74 jmp cont 75 is_not_single: 76 lock xadd dword ptr [ecx],eax 77 cont: 78 inc eax 79 } 80 } but above all this comment some lines above in this same file: /* For all Intel x86 above x486 we use a spezial inline assembler implementation. The main reason is that WIN9? does not return the result of the operation. Instead there is only returned a value greater than zero is the increment result is greater than zero, but not the result of the addition. For Windows NT the native function could be used, because the correct result is returned. Beacuse of simpler code maintance and performace reasons we use on every x86-Windows-Platform the inline assembler implementation. */ since min Windows version for LO >= 4.0 is WinXP, could this part be removed or simplified?
Fridrich S.: the comment under the youtube video reads: "please supply the community with pdb files" ;-> Tor: is this interlocking assembler a legacy of Windows 9x that we can kill in master. Julien: it is extremely unlikely that the interlock is the real problem I think :-) more likely that it is the first guy to touch memory that was just freed. Friedrich: thanks so much for debugging; and the great bug report - I'd hope the problem would show up in digging through the valgrind log; let me look ...
==9824== Invalid read of size 4 ==9824== at 0xE9ABA77: ??? (in /opt/libreoffice/basis3.3/program/libvclplug_kdelx.so) ==9824== by 0xE9AF742: ??? (in /opt/libreoffice/basis3.3/program/libvclplug_kdelx.so) ==9824== by 0x9748DD5: SalGraphics::DrawNativeControl(unsigned int, unsigned int, Rectangle const&, unsigned int, ImplControlValue const&, rtl::OUString const&, OutputDevice const*) (in /opt/libreoffice/basis3.3/program/libvcllx.so) This doesn't look so good ;-) it's the first failure on Linux. Can you re-try under GNOME, and/or install your system's debuginfo package for that machine so we can get a better valgrind trace ? looks like you've fallen over a KDE specific problem there (potentially) but perhaps it's common to all backends given that it happens on Windows too. Thanks !
@Friedrich: please try to get a backtrace using updated http://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg and msi debug build from http://dev-builds.libreoffice.org/windows-debug/msi/ Unfortunately source files are still missing.
Created attachment 79682 [details] WinDebug output including stacktrace. Added backtrace. Created on Windows 7 64-bit with http://dev-builds.libreoffice.org/windows-debug/msi/LibO-Dev_4.0.3.0_Win_x86.msi and libreoffice-4.0.3.3.tar.xz
NEW as bug still reproducible and bt attached.
I have the same crashing on exporting an opd with a lot of pictures (TIF files) embedded. By a lot I mean: with 270 pictures it was still OK, but now I got up to 360, and now the process crashes consistently with terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc I take the standard settings of the export, but include the notes, which are not many. I can provide you the odp I you want it . Currently 951Mb.
Forgot: Mageia 3, LibreOffice 4.0.4.2 on a AMD 64 bit with 8Gb memory.
WORKSFORME. When opening "Simple file that causes crash on PDF export" test1.odt and using LOs own ODF export everything runs smooth on OS X 10.8.4, LO 4.2 master 2013-08-20. Can anybody still confirm crashes with test1.odt and LO 4.1.1.1 or later on any platform? Herman: can you attach your gigantic test document? So we can further test this? Otherwise I tend to put this on WORKSFORME, if we don't get any crashing reports with the current test document and latest LO releases.
test1.odt can be easily exported to PDF with LibO 4.1.2.3 under Win7 64bit. set status to RESOLVED WORKSFORME
Give yourself something to anticipate once you've completed the exposition, as this will assist with persuading you to finish it. It could be a chocolate bar, the guarantee of viewing a scene of your preferred network show, or a night out with companions – anything that will give adequate impetus to get your article wrapped up. You've worked seriously and have an incredible article to appear for it. By: https://articleoftheweek.com/2020/01/26/what-is-comptia-cdia-certification/