Writer crash Neooffice Writer 3.2 beta patch 2

[timrichardson]

Crash occurred while trying to print a 56 page document. Swap file use was quite spectacular.

[pluby]

Your crash log indicates that the crash is occurring within one of Mac OS X's "write image bytes to temporary PDF file" functions. Since the native Mac OS X print functions write all content to a temporary PDF and you mentioned that you have massive amount of swap file usage is it possible that you ran out of disk space on your machine's main hard disk?

Patrick

[pluby]

I forgot to add that if you are seeing large swap file usage while printing from NeoOffice, that usually indicates that you have some very large or high resolution images within your document. While NeoOffice Writer will scale down and reduce image resolution when displaying a document on screen, printing will display a document in its full, original resolution in the temporary PDF file that the Mac OS X printing functions create.

Do you have any large images in your document (that, greater than 1000 x 1000 pixels)? You can see the full, original size of an image by right-clicking or Control-clicking on an image and, in the popup menu that appears, selecting the Picture menu. In the dialog that appears, click on the Crop tab and multiply the size just above the Original Size button button by 96 dots per inch (or 38 dots per centimeter).

Patrick

[timrichardson]

Well, the machine's disk has 400GB free. swap didn't approach that.

It also crashed while creating a PDF. However, I have just created a PDF in LibreOffice 3.3.2
OOO330m19 (Build:202)
and it prints ok as well, with much, much lower memory use.

There are some large images in the document. It's 5.1 MB and only compresses to 5MB. I've no problem sending it to you if it helps, but it's too big to attach.

[pluby]

[timrichardson]

file is attached

[pluby]

Thank you for the sample document. I just tested the document by pressing the Preview button in the print dialog and after a few minutes the print output appeared in the Preview application. There was no crash but since I am using Mac OS X 10.5.8, maybe this bug only occurs on Mac OS X 10.6.7?

I will reboot into 10.6.7 later this morning. In the meantime, can you tell us if this crashing occurs when you press the Preview button in the print dialog like I did? If the crash does not occur and the print output displays in the Preview application, can you successfully print from the Preview application to your printer or does the Preview application crash?

Patrick

[pluby]

Unfortunately, I could not reproduce the crashing on Mac OS X 10.6.7 or 10.7 Developer Preview 2. Since I have made some small changes in the NeoOffice 3.2 Beta code to fix some menubar issues, it is possible that my small changes somehow prevent the crash from occurring.

So, can you install the following test patch and press the Preview button in the print dialog? Does the print output open in the Preview application or does NeoOffice still crash?:

Intel:
http://joe.neooffice.org/test/NeoOffice-3.2_Beta-Patch-2-Test-2-Intel.dmg

Patrick

[timrichardson]

Hi Patrick. Before applying the patch, I tried the preview button.
Behavior is the same. Real Memory use peaks at 1.3GB, swap heads towards 3GB (machine has 4GB physical RAM), it crashes while preparing the final page.
For what it's worth, LibreOffice real memory use stays below 400MB when working with the same document.

Now I'll try the patch you refer to.

[timrichardson]

I'm afraid it crashed even after the patch (preview option from print dialog).
Are there preference settings that could affect this? Thinking of memory preferences. I'll see if I can set them back to default.

[timrichardson]

I reset the memory settings in preferences to defaults (actually, I copied the LibreOffice settings which is probably the same thing). NeoOffice no longer crashes, although max real memory usage is still very high.
Settings I had:
Undo steps: 50 (now back to 100)
Graphics cache:
Use for NeoOffice: 50MB (now back to 200MB)
Memory per object: 20 MB (now back to 1 MB)
Cache number; 25 objects (now back to 20)

[pluby]

Your results agree with what I found since my last post: NeoOffice's underlying OpenOffice.org code is running out of memory. Even when you have more than 4 GB of physical memory and swap, NeoOffice and OpenOffice.org cannot access more than 4 GB of memory. This is the limit for all 32-bit applications.

Normally, this "per application" memory limit is not a problem, but when printing a document with lots of images, both NeoOffice and OpenOffice.org 3.1.1 (the version that NeoOffice is based on) will create high resolution copies of your document's images in memory to send to the printer and will not release any of that memory until the entire print job is done.

So, in your document, memory use soars after each page with images in it is rendered. Interestingly, because our NeoOffice code does such special image handling that OpenOffice.org 3.1.1 does not do - we handle images of varying resolutions in a single document whereas OpenOffice.org scales all images to a single resolution - OpenOffice.org 3.1.1 will crash earlier than NeoOffice. Also, strangely, while LibreOffice 3.3.2 doesn't use as much memory, it creates PDF files nearly 5 times larger than NeoOffice.

I am going to take a look at the OpenOffice.org print drawing queue code and see if I can force the OpenOffice.org to purge its graphics cache after each page. In the meantime, I have a workaround to avoid the OpenOfifce.org code's excessive memory usage when printing:

Select the File :: Export as PDF menu - This will almost always create PDF files that are only a fraction of the size that NeoOffice's print code creates. This is because the Export as PDF feature is designed to make the smallest possible PDF files. The only downside is that images will usually be limited to 300 dots per inch. That is usually enough for your average printer but probably not high enough resolution for brochures and other advertising media.

I will post again when I have some more information on whether or not I am able to get NeoOffice's underlying OpenOffice.org code to clear its graphics cache after each page.

Patrick

[pluby]

I think that I have fixed this excessive memory usage while printing. After reviewing the modifications to the OpenOffice.org print drawing queue code that I made several years ago, I saw that it was my customizations that were holding on to images in memory until all pages were printed.

I originally implemented this customization because we using Java for some of the printing code and until Java 1.4 this customization was needed to prevent deadlocks while printing. However, now that we only support Java 1.5 and higher in NeoOffice 3.2 Beta, this customization is no longer needed so I have removed it. The customization will remain in NeoOffice 3.1.2 since that release supports Java 1.4.

Can you install the following test, reboot to clear all of the existing swap files, and try pressing the Preview button in the print dialog? Is swap usage signficantly lower than before?:

Intel:
http://joe.neooffice.org/test/NeoOffice-3.2_Beta-Patch-2-Test-3-Intel.dmg

Patrick

[timrichardson]

That makes a radical difference. Memory use is < 400MB at peak, and it's faster as well, of course, without all the swapping.

[pluby]