Apache OpenOffice Community Forum

Hi, there everyone,

I'm in a bit of a trouble here. I'm just about to finish an important thesis in OpenOffice and did not encounter any problems at all till a few days ago Writer started to crash regularily.

I'm using OpenOffice 3.2 with the latest JRE on Windows Vista (SP2) to do the work.

Now OpenOffice works just fine, until I try to save the document (which is roughly 200 pages and 150 pictures - linked, not loaded into the document - in size).

When saving, Openoffice starts to eat memory like crazy. My computer has 2 GB of main memory. The crash occours, when Openoffice fills 1,5 GB of that. A box with the following pops up:

Microsoft Visual C++ runtime Library

Runtime Error!
blahblahblah\soffice.bin

........


I searched the forums in advance to this post and as a result tried to reset my user profile, tried to install the newest JRE and even reinstalled OpenOffice after whiping every trace of it, which is what caused similar memory consumptions in the past.
I did a virus scan of my computer with latest definitions which found nothing, too (has been the reason for another memory-consumption related crash) and I tried shutting down all the other programs on the computer (from task manager) until only Vista and Ooffice ran - in case the problem is occuring only when a special program is running - but every time the crash occoured none the less.

I'm really quite out of options now. Any help is welcome!

Hi and welcome to the forum!

I haven't experienced any crash at save but I do see that OOo 3.2 is less stable than former versions. I'm really wondering if I won't go back to 3.1.1. Sometimes I can't launch OOo. There can be several soffice.bin processes in the task manager but nothing on screen. And sometimes, it crashes when I open a document. But never had any runtime library error message. It just goes to the recovery process directly.

If you've the quickstarter activated, try to switch it off.

Hi, there,

thanks for the fast reply,

ok - quickstarter on or off - no difference - crash reproducible.

Downgrade to Ooffice 3.1.1. Crash reproducible.

My pictures are of quite high resolution.I tried converting them to smaller ones and the crash vanishes. Sadly for the final version I have to have 600dpi resolution and not only 300dpi. So still help with that problem would be very welcome.

Dukram wrote:Hi, there,

thanks for the fast reply,

ok - quickstarter on or off - no difference - crash reproducible.

Downgrade to Ooffice 3.1.1. Crash reproducible.

My pictures are of quite high resolution.I tried converting them to smaller ones and the crash vanishes. Sadly for the final version I have to have 600dpi resolution and not only 300dpi. So still help with that problem would be very welcome.

Just a suggestion but could you get your hands on a PC with a lot more memory?

uffff. In principle yes, but not for long. And still I have to change some things in the doc ..... which is some weeks of work.

But you're right - that might help.

None the less - what does OpenOffice do there to have such a huge memory consumption when saving? Does it load all pictures or what? Can that be circumvented?

(oh - btw - I'm quite sorry for bad english .... its not my native language ....)

Adjust Tools / Options / OpenOffice.org / Memory. Just what settings you use is a matter of experiment. Also, normally to insert pictures into a file of a resolution greater than 150/200 dpi is normally unnecessary, as the output resolution is typically 150-180 dpi when printed.

Yeah - well usually, you would be completelly right, but in this case, the thesis will be published and the printers there are capable of 600dpi resolution (so I've been told) - which thus they wanna have in the document in the end ....

Besides - the document will be available as pdf, for download, too - and if you use the zoom-tool for zooming into graphs, it really matters if you have 150 or 600dpi .... sadly for me .....

as for the memory-settings - I already tried playing with these. And what they can do, is they really manage faster loading times etc. etc., but none the less they do not seem to influence the enormous memory consumption on saving - which seems to be the reason for the crash.

Hi, again,

so - first of all - thanks for your suggestions. Indeed the crash is memory-related and does not show up if one uses a computer with more than my 2 GB RAM or if one reduces the size of those pictures drastically.

My workaround for now is only to use pictures of less quality while writing (thank god I only linked those pics) - and substituting those for the high quality pics in the end. But then I will use a firends workstation with 12 GB RAM - which hopefully will be enough.

None the less I'm going to file a bug report. No office package should crash due to memory issues and especially not while trying to save the document.

To pick up one point from the earlier discussion: the printers used for printing may be 600dpi, but eyes are eyes, and unless one is doing critical examination with magnifiers, for which one might need to be using _real_ photographs, the accepted wisdom is that one need not supply for print images with a greater resolution than about 200dpi. If you can, it is worth supplying two copies of the same image - one 200 dpi, the other 600 dpi - and asking for a test print.

I have the same issue. The saving process looks like:

1. Saving - progress bar is visible, saving time depends on document's size and DPI of images. Memory usage is low. If there are only links to images (they are NOT embedded), saving is quite fast.

2. Building file - progress bar is hidden but interface is inactive. If there are lots of high-quality images, memory usage grows rapidly and OpenOffice crashes. In case of about 50 images scanned as 300 DPI memory usage reaches over 800 MB and takes over 10 minutes. How much will it reach in case of 2000 images scanned as 300 DPI and a big text book?

This problem exists even if all images are only linked, not bundled!

My hardware: Athlon 2000+ 1.6 GHz, 256 MB RAM, WinXP Home SP3

This problem should not be marked as Solved, since at best there is only a workaround and the workaround requires using a different machine.

In any case, I am having this problem too. I'm finding it hard to believe that such a basic issue as saving a file with lots of large images crashes OO isn't a huge issue that is all over the web, but this is the only place I've seen it mentioned. Kinda makes me wonder who the clientel are for OO. Are theses really being written using OO Writer? And this doesn't come up?

Incidentally I tried OO 3.3 and Libreoffice 3.3 and they both crash too. If you embed the images instead of providing links it doesn't crash, but some of the images don't show --- this is already mentioned all over the web and has been a problem for years on OO apparently.

This is a real showstopper for me. Having wasted many hours on this already, I may have to switch back to Word.

I'm curious if this is only a problem on Windows machines. I can't easily move the document to my Linux machine as this is a document at work on the protected server.

-John

It might be worth adjusting the size of the Swap File; Right click on My Computer, select Advanced Tab and Performance Options and change the size for Virtual Memory, perhaps setting this to at least the size of your RAM, and perhaps twice that. It may make no difference, but it is worth a try.

Edit: You may have to restart your computer for this to take effect.

Changing the size of the swap file and restarting is a good idea, but unfortunately I already tried that.

I tried OO 3.2 on Ubuntu 10.04 (lucid) and got the same crash with this message:

"terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc

Which version did you use? Did you compile it yourself?

it's the Stock OO 3.2 binary that comes with Ubuntu 10.04

Try the version from www.openoffice.org

I already tried the latest 3.3 version from openoffice.org for WIn32. I don't see a reason why results from the latest version in Linux from openoffice.org will be different, given that the problem exists in Linux and Win32 of 3.2 as well. I think I need to move on. Thanks for your help.

I have had 3.2 and currently 3.3 running well under Ubuntu 10.10, and earlier versions previously under 10.4. I use the version from Oracle.

I have this problem also for a large master document in which I have about 150 sub-documents each of which originally contained a link to a PNG image file. The biggest issue I face is getting a correct Table of Contents in the saved master document.

I have found that embedding the images in the sub-documents instead of linking solves the save issue for the master document. The problem with missing images I solve by updating the links for all sub-documents in batches of 30 and making sure that the page numbers are correct. Then I generate the Table of Contents. I can then save the master document. What I finally need is a PDF printed version of the document. I do this by generating PDF output in successive sets of 30 pages which I glue together with an external tool outside OO. This way at least I can go from text to printed output and a saved Master document with correct ToC. As I generate the sub-documents semi-automatically, this way of working still beats the alternatives.

Still, I would very much like to see this issue solved - the memory handling during a save should be a solvable item. If one of the developers needs, I can create a dummy document that shows the behavior with half an hour's work; just let me know.

Cheers,
Marq

A reasonable suspicion might be that the problem is in OOo's memory handling. Inspection of the memory settings (/ Tools / Options / OpenOffice.org / Memory ) shows that they are, by modern standards, conservative. Perhaps the proposed re-write under the LibreOffice banner may solve this.

It is not unusual for images to be inserted into OOo at too high a resolution, thereby leading to larger files (if embedded) or bigger imports if linked. If output is being printed on standard laser printers a useful rule of thumb is that continuous tone images do not need resolutions higher than about 200 dpi. Line images are acceptable in many cases at 300 dpi, although 600 dpi is better.

The Oracle (formerly Sun) Presentation Minimizer has been the saviour of many users preparing presentations. It embeds the graphics files, removes unused material, and reduces the resolutions to optimal for the desired display device (customisable) and saves the entire presentation in a compact form. I have seen it reduce 80MB presentations to 4MB with no loss of presentation quality. The source code for this is available. My dream is for some enterprising person with time on his hands to modify this for Writer documents - I live in hope!

Unfortunately the developers do not normally frequent this list, so they do not benefit from our brilliant ideas!

Unfortunately, the document I produce does need the high resolution: they are mostly line images and are for printed documentation. The PNG files I use are mostly around 400KB in size, but I don't know what OOo does internally with these files - PNG is a compressed format and an expanded format can perhaps reach 5 MB. What I did do to be able to produce the sets of PDF files is to increase the graphics memory to 256MB and use 5.0 Mb per object (Tools --> Options --> General --> Memory). This allows a complete set of images to be updated for PDF export - sufficient to produce a file with 40 continuous pages of content without an image loading problem.

MarqKole wrote:Unfortunately, the document I produce does need the high resolution: <snip>

I was thinking generally, rather than with specific reference to your case. It is interesting to note the way you managed to solve the problem; I hope other users with a similar problem will take note.

Hi everybody, I'm glad somebody is discussing this thing, I've been taking notes on OpenOffice 3.2.1 in Ubuntu 10.10 for some time now and it is a little annoying that on saving it takes 100% CPU and about a bunch of seconds to save the file, If I just edit one letter, just one letter, it seems to save the entire file.
My file is about 70 pages of notes on whatever, say Math, Physics, and it's just writing, not many pictures, very few pictures.
I just checked the Memory section in Options but I don't understand much of those options, I might have to Google for them. Anyway, I'm not complaining because so far Open Office has not crashed on my Ubuntu, all I'm saying is that if you go to Microsoft Word 2000 --oldie, why not-- and save a document it saves very fast! Kinda like my dreams would be like for OpenOffice.

With Ubuntu, you can try the vanilla version instead of the Ubuntu build: [Ubuntu] Installing OOo on Debian and Co. Several users have reported a faster behavior.

I experience the same problem, large document with 1000 linked images.
Bypass: make all of the image files read-only. After that saving is smooth, in seconds instead of minutes and no crashes.
But the next problem remains, OO will crash when printing or generating PDF.

I think 1000 images is pushing any word processor to the limits. You should consider moving to a page layout program. Adobe Indesign is often used commercially. Scribus is a free download.

I've also had this issue with Oo crashing on large mb files. I was using Ubuntu at the time, but wrongly assumed that it was my computer, as my specs for that computer was pathetic. I was trying to save a 250 x 250 square sudoku game.

I'm now on a Windows 7 with 8GB Ram. I intend to write a 400,000 word novel for NanoWrimo in a word wars contest. However, after reading this thread, I wonder if a solution might be to simply...

1) Break down the file into smaller chunks and save.
2) Save all the smaller chunks into a separate pdf files.
3) Take a PDF file maker that can merge several pdf files into one pdf file.
Not a solution, but another work around.

Instead of saving several PDF, you can at least use the master document feature.

We were discussing when the document is too large for Oo to handle it properly, such that it kept crashing while saving it. I'm not sure if the master document feature gets around the very issue that this thread was discussing, and that is CPU intensive documents.