Welcome to NeoOffice developer notes and announcements
NeoOffice
Developer notes and announcements
 
 

This website is an archive and is no longer active
NeoOffice announcements have moved to the NeoOffice News website


Support
· Forums
· NeoOffice Support
· NeoWiki


Announcements
· Twitter @NeoOffice


Downloads
· Download NeoOffice


  
NeoOffice :: View topic - Writer crash Neooffice Writer 3.2 beta patch 2
Writer crash Neooffice Writer 3.2 beta patch 2
 
   NeoOffice Forum Index -> NeoOffice Beta Releases
View previous topic :: View next topic  
Author Message
timrichardson
Pure-blooded Human


Joined: Oct 07, 2007
Posts: 39

PostPosted: Tue Apr 05, 2011 5:35 am    Post subject: Writer crash Neooffice Writer 3.2 beta patch 2

Crash occurred while trying to print a 56 page document. Swap file use was quite spectacular.
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Tue Apr 05, 2011 5:48 am    Post subject:

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
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Tue Apr 05, 2011 6:04 am    Post subject:

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
Back to top
timrichardson
Pure-blooded Human


Joined: Oct 07, 2007
Posts: 39

PostPosted: Tue Apr 05, 2011 6:16 am    Post subject:

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.
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Tue Apr 05, 2011 6:26 am    Post subject:

timrichardson wrote:
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.


Since it is too large to post here, can you upload the sample document to a of free upload site like megaupload.com or uploading.com and then post a link to the document here?

Edit by pluby: Before you use a free upload site, try attaching the sample file. I have temporarily increased the attachment size limit so you hopefully can now attach it.

Patrick
Back to top
timrichardson
Pure-blooded Human


Joined: Oct 07, 2007
Posts: 39

PostPosted: Tue Apr 05, 2011 6:42 am    Post subject:

file is attached
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Tue Apr 05, 2011 7:02 am    Post subject:

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
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Tue Apr 05, 2011 8:44 am    Post subject:

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
Back to top
timrichardson
Pure-blooded Human


Joined: Oct 07, 2007
Posts: 39

PostPosted: Tue Apr 05, 2011 1:54 pm    Post subject:

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.
Back to top
timrichardson
Pure-blooded Human


Joined: Oct 07, 2007
Posts: 39

PostPosted: Tue Apr 05, 2011 2:01 pm    Post subject:

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.
Back to top
timrichardson
Pure-blooded Human


Joined: Oct 07, 2007
Posts: 39

PostPosted: Tue Apr 05, 2011 2:12 pm    Post subject:

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)
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Tue Apr 05, 2011 4:58 pm    Post subject:

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
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Tue Apr 05, 2011 10:23 pm    Post subject:

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
Back to top
timrichardson
Pure-blooded Human


Joined: Oct 07, 2007
Posts: 39

PostPosted: Wed Apr 06, 2011 12:31 am    Post subject:

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


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Wed Apr 06, 2011 9:25 am    Post subject:

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


That is good to hear that it works for you. The nice thing about this change is that I did not have to modify the underlying OpenOffice.org code logic and only had to remove a very old hack to support Mac OS X 10.4 and older versions.

I am definitely glad that we no longer need that old hack. Also, without that hack, you can now switch to and edit a non-printing document while another document is printing.

Patrick
Back to top
Display posts from previous:   
   NeoOffice Forum Index -> NeoOffice Beta Releases All times are GMT - 7 Hours
Goto page 1, 2  Next
Page 1 of 2

 
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Powered by phpBB © 2001, 2005 phpBB Group

All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © Planamesa Inc.
NeoOffice is a registered trademark of Planamesa Inc. and may not be used without permission.
PHP-Nuke Copyright © 2005 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.