Bug 32771 - Writer crashes while exporting big PDF file. (Error message: "Der Wecker klingelt" :-))
Summary: Writer crashes while exporting big PDF file. (Error message: "Der Wecker klin...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) All
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: haveBacktrace
Depends on:
Blocks:
 
Reported: 2011-01-01 17:19 UTC by Friedrich
Modified: 2013-12-17 23:02 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
short strace log file (9.01 KB, application/zip)
2011-01-01 17:21 UTC, Friedrich
Details
short version of valgrind log without memory leak analysis (13.41 KB, application/zip)
2011-01-01 17:24 UTC, Friedrich
Details
full valgrind log (Part 1) (822.67 KB, application/zip)
2011-01-01 17:27 UTC, Friedrich
Details
full valgrind log (Part 2) (992.29 KB, application/zip)
2011-01-01 17:30 UTC, Friedrich
Details
Simple file that causes crash on PDF export (8.83 KB, application/vnd.oasis.opendocument.text)
2012-03-21 13:17 UTC, SRS
Details
WinDebug output (created without debug infos) (32.53 KB, text/plain)
2013-03-15 14:37 UTC, Friedrich
Details
WinDebug output including stacktrace. (34.91 KB, text/plain)
2013-05-22 19:20 UTC, Friedrich
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Friedrich 2011-01-01 17:19:18 UTC
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.
Comment 1 Friedrich 2011-01-01 17:21:53 UTC
Created attachment 41557 [details]
short strace log file
Comment 2 Friedrich 2011-01-01 17:24:31 UTC
Created attachment 41558 [details]
short version of valgrind log without memory leak analysis
Comment 3 Friedrich 2011-01-01 17:27:22 UTC
Created attachment 41559 [details]
full valgrind log (Part 1)
Comment 4 Friedrich 2011-01-01 17:30:30 UTC
Created attachment 41560 [details]
full valgrind log (Part 2)
Comment 5 Friedrich 2011-06-09 13:02:14 UTC
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!
Comment 6 Jeffrey 2011-07-21 07:48:50 UTC
*** Bug 39411 has been marked as a duplicate of this bug. ***
Comment 7 narayanaras 2011-07-21 19:23:18 UTC
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.
Comment 8 Björn Michaelsen 2011-12-23 11:35:16 UTC
[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
Comment 9 Friedrich 2011-12-29 06:52:44 UTC
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
Comment 10 Cor Nouws 2012-02-09 07:59:32 UTC
(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
Comment 11 Friedrich 2012-02-20 10:05:20 UTC
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
Comment 12 SRS 2012-03-21 13:10:42 UTC
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.
Comment 13 SRS 2012-03-21 13:17:06 UTC
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".
Comment 14 SRS 2012-03-21 13:20:22 UTC
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.
Comment 15 Cor Nouws 2012-04-11 00:48:59 UTC
(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
Comment 16 Roman Eisele 2012-05-03 04:42:20 UTC
-- 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.
Comment 17 Julien Nabet 2012-05-05 10:01:38 UTC
(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.
Comment 18 Hylton Conacher 2012-07-31 14:08:48 UTC
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.
Comment 19 Roman Eisele 2012-08-01 07:36:35 UTC
(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!
Comment 20 Julien Nabet 2012-09-22 22:15:58 UTC
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)?
Comment 21 Friedrich 2012-10-26 12:41:55 UTC
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.)
Comment 22 Julien Nabet 2012-10-26 20:54:14 UTC
(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)?
Comment 23 Julien Nabet 2013-01-09 21:23:28 UTC
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.
Comment 24 Friedrich 2013-02-11 22:04:56 UTC
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.
Comment 25 David 2013-03-06 21:15:47 UTC
I've also been experiencing this problem for a long time.  Version 4.0.2RC2 still exhibits this issue.
Comment 26 Julien Nabet 2013-03-07 21:08:34 UTC
Friedrich/David: could you attach the odt file so we can try to reproduce?
Comment 27 David 2013-03-08 14:54:31 UTC
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.
Comment 28 Friedrich 2013-03-15 14:32:47 UTC
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 */
}
Comment 29 Friedrich 2013-03-15 14:37:29 UTC
Created attachment 76561 [details]
WinDebug output (created without debug infos)
Comment 30 Julien Nabet 2013-03-15 22:39:17 UTC
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?
Comment 31 Michael Meeks 2013-03-16 18:59:12 UTC
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 ...
Comment 32 Michael Meeks 2013-03-16 19:39:34 UTC
==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 !
Comment 33 bfoman (inactive) 2013-05-21 09:34:56 UTC
@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.
Comment 34 Friedrich 2013-05-22 19:20:11 UTC
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
Comment 35 bfoman (inactive) 2013-05-22 20:15:15 UTC
NEW as bug still reproducible and bt attached.
Comment 36 herman.viaene 2013-08-20 08:17:33 UTC
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.
Comment 37 herman.viaene 2013-08-20 08:19:21 UTC
Forgot: Mageia 3, LibreOffice 4.0.4.2 on a AMD 64 bit with 8Gb memory.
Comment 38 retired 2013-08-20 09:56:54 UTC
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.
Comment 39 tommy27 2013-10-10 20:24:56 UTC
test1.odt can be easily exported to PDF with LibO 4.1.2.3 under Win7 64bit.

set status to RESOLVED WORKSFORME