Apache OpenOffice Community Forum

Just installed 4.1.2 and it has the same "bad allocation" error as 4.1.1 when opening several large spreadsheets (>3.5MB) with lots of complex formulas. Are there any settings in OpenOffice which would increase the size and number of spreadsheets which can be handled?

Are you saving the spreadsheets as .xls? If so, switching to .ods should increase the capability of OpenOffice to handle the larger files.

The spreadsheets are all .ods files.

It seems to be a shortcoming of the software. At least one issue report has been filed : Calc Consistently crashing, usually with "Fatal Error - Bad Allocation". A similar issue seems to be present in LibreOffice.

Another thread on the subject.

kingfisher wrote:It seems to be a shortcoming of the software. At least one issue report has been filed : Calc Consistently crashing, usually with "Fatal Error - Bad Allocation". A similar issue seems to be present in LibreOffice.

Another thread on the subject.

That issue seems to suggest it is a Windows X AOO interaction? At least, that's how I'm reading it.

The problem has occurred on 4.1.1 running on windows 7 and 10 and 4.1.2 on windows 10. I haven't been able to reliably re-produce the bad allocation message, but I can crash OO at will just by opening a second large spreadsheet with lots of formulas - (really just a copy of the first). The second spreadsheet loads, but OO crashes while attempting the calculations. I can also get OO to lock up by trying to open the spreadsheet copy after recovering from a crash. I think this really is a problem for the CALC people to look into.

It may help to remove the selection of Tools > Cell Content > AutoCalculate.

RonBlackwell wrote: I think this really is a problem for the CALC people to look into.

They have been. See Kingfisher's link to the bug report above. It might help if you contributed a report or even submitted a file.

It may also be something MicroSoft should look into; none of the error reports are from Mac or Linux OSs.

You could try a somewhat elaborate test. Burn a Linux boot CD and see if you get the same problem if you run Linux. It is fairly easy to create boot CD for something like Ubuntu or Uberstudent, the two distros I am acquainted with and both come with LibreOffice.

I tried kingfisher's suggestion of turning off autocalculate but that didn't alter the results. Watching OO, the spreadsheet loads, then begins calculating. There is a long pause in the progress bar during the calculating, always about the same place. Watching OO on windows 10 task manager shows OO as "not responding". Eventually, OO does display the first spreadsheet and starts responding again. When opening the second spreadsheet, it crashes at that point.
If I disguise the data a bit more, I can give the spreadsheet to others to try replicating the problem.

If I disguise the data a bit more, I can give the spreadsheet to others to try replicating the problem.

Excellent idea. I am really curious so see if it duplicates on a Mac or Linux box.

I added a comment to the bug in kingfisher's link, but I could not attach the spreadsheet since it is too big (almost 4.7MB). Trying to cut the size down by deleting about half the formulas may not work: I got a bad allocation message when trying to save it after deleting a bunch of lines. Really nasty bug..

I'm having the same problem in OO 4.1.1 on Windows 8.1, but only in extreme cases. I need to handle several large "data" spreadsheets, under control of a master spreadsheet and Basic macros, and retain access to all of them. So I open all of them. Watching memory usage under Task Manager, I see the allocation to OO grow in stages from about 800MB to about 1500MB. That all works just fine. But when I close all of them and try to do something else, I get an allocation error from deep down in the C++ routines. The tipping point seems to be when the total allocation approaches 1.5GB, although I have an 8GB machine.

I have always felt that allocations go OK, but when something is closed and the storage for it is deallocated and possibly subjected to garbage collection within Calc or Windows, something in there fails and messes up the data structures that describe the available memory, and a subsequent allocation attempt fails.

You should add a comment to the bug in kingfisher's link; if this is a problem with allocation/deallocation one of the devs will pick it up from there. It is possible that the file has not been tested with such an extreme set of files.

RoryOF wrote:You should add a comment to the bug in kingfisher's link; if this is a problem with allocation/deallocation one of the devs will pick it up from there. It is possible that the file has not been tested with such an extreme set of files.

I had to create an account over on the bug reporting site in order to post my message there. It said that an e-mail had been sent to me that I needed to reply to in order to finish setting up the account. Now, several hours later, no such e-mail has arrived in my inbox or junk mail folder.

I managed to cut down the size of my spreadsheet to 957KB so I posted it to Bugzilla Issue 125006 (kingfisher's link). It takes more open copies to cause a crash, because it uses less storage for formulas, about 400MB versus 940MB. Interesting thing with the full version is that during the initial calculations when it is opened storage zooms past 1000MB, at which point OO becomes unresponsive, to more than 1300MB. Something comes along and cleans up, if you wait long enough, and storage drops to 922MB. If you try to increase the number of lines the spreadsheet can handle to more than 5000 or 6000, CALC becomes unusable - the cursor goes all funny and nothing works.

I have raised this matter on the Developer mailing list. As it is a borderline case and concerned with memory allocation/deallocation problem it may not be immediately soluble.

I installed 4.1.1 a few weeks back and have had 'bad allocation' error message when closing calc files. It hangs about 1/3 way through the save process.

As suggested in a previous post, I have reverted to 4.0.1 to see if the error persists.