Apache OpenOffice (AOO) Bugzilla – Issue 125006
Calc Consistently crashing, usually with "Fatal Error - Bad Allocation"
Last modified: 2022-09-06 19:03:25 UTC
Unless saving after every line of input on a simple row and column chart, Calc is consistently crashing with the "Fatal Error - Bad Allocation" error message, or just completely freezing. I've reloaded 4.1.0 and it is still creating the same errors.
NOT reproducible with "AOO 4.2.0-Dev – German UI / German locale [AOO420m1(Build:9800) - Rev. 1597166 2014-05-20 1]" on German WIN7 Home Premium (64bit)", “historic” 4. User Profile used for all predecessor versions But I already saw some few times that error message with latest AOO versions, I can't remember whether with Calc or other AOO applicatons. @paulstevensinoc: We need an instruction how to reproduce your problem and a sample document.
This one might be related to or DUP of "Issue 124064 - Document with Chart for lots of values causes CRASH with message "Fatal Error - Bad Allocation"" "Issue 124522 - Memory leak opening OOo 3.2 .ODF in newer releases" "Issue 123900 - Very slow switching to Chart Edit Mode" @paulstevensinoc: Please test whether your problem persists after you have renamed your user profile (Quit Quickstart before!) before you launch AOO (please see <https://wiki.openoffice.org/wiki/Documentation/How_Tos/Handling_the_OpenOffice.org_User_Profile>
(In reply to paulstevensinoc from comment #0) > Unless saving after every line of input on a simple row and column chart, > Calc is consistently crashing with the "Fatal Error - Bad Allocation" error > message, or just completely freezing. I've reloaded 4.1.0 and it is still > creating the same errors. The reason is likely, that you try to use too many data points. That problem was handled in bug 122822, but not solved. The automatic point reducing tried there was unsatisfying and dropped, but a new solution for automatic reducing is not found yet. Bug 123900 is still open. Please try, whether the chart works, when you use less data points (less than 8000).
when adding a bitmap to fill a comment, then, a bad allocation error happens, 9 times out of 10, when saving the file. If the file has 20 or 30 lines, no problem. When the file has more than 900 lines, a big crashing problem. So here a link to the file, which is 95 Mo (so i can't join it here) http://ul.to/0eftxg2s Tx for your help, this bug is really boring
the crashes and freeze-up within calc have been since using Windows 8. It happens when entering multiple formulas on spreadsheets which have never crashed previously. could this be a bug in the operating systems?
20141206-experiencing this problem frequently-it appears to be a memory allocation error. worksheet just freezes - cannot do anything - must restart computer to clear. windows 8.1 lenovo 128g ss memory
Windows 8.1 TOSHIBA Satellite L55t-A Intel Core i5-4200U CPU 1.60GHz 2.60 GHz RAM 8.00 GB 64-bit OS, 64-based processor AOO410m18(Build:9764) - Rev. 1589052 2014-04-22 11:43:54 (Di, 22 Apr 2014) I'm "camping on" to issue 125006. It's intermittent, but I have tons of experience with it. For months, I have unsuccessfully been trying to replicate this problem. And yet I replicate it all the time in my daily work with AOO Calc. So here goes... To reproduce the problem in AOO: Either start with a virgin Calc spreadsheet or use an old complicated spreadsheet full of formulas and Pivot Tables. Whether working with an old Profile or a recently reset Profile does not seem to matter. Do heads-down data entry or develop new columns with formulas - any mix of activities. Save often. Do other work with your computer such as using a browser to look at your email - or refrain from that. Download from a website, then Insert/Sheet From File. Or don't. Copy text from browser window to cells - or not. Take your time. Don't hold your breath -- but neither can you say "NOT reproducible" after 10 or 20 minutes. Using the above procedure, I get "Open Office 4.1.0 - Fatal Error /!\ bad allocation" several times a week, sometimes up to 4 times a day. I have a folder in Microsoft OneNote that is filling up with screen-shots of what the window looked like when I got "bad allocation", plus notes as to what I was doing at the time, and how the recovery went. Typical notes (some paraphrasing): "Just data entry. Cursor became a plus sign. Tried to save - bad allocation." "Brand new spreadsheet - trying to select an area" with a screen-shot showing a messed-up area on the display, overlaid by the "bad allocation" window. "Pasted from clipboard after not saving from 2:07 to 2:22 - bad allocation" "Heads-down data entry stops accepting input. After a while, input becomes possible again. Immediate Save results in immediate crash (i.e., AOO 'Document Recovery' window)" Granted, the last example is of a failed Save. It did produce 'bad allocation', but Save has been implicated all along as well. By the way, I have had to try LibreOffce. I have not seen 'bad allocation' there yet.
Amendment to Comment 7, toward the bottom... Granted, the last example is of a failed Save. It did produce 'bad allocation', but Save has been implicated all along as well. It did NOT produce 'bad allocation'. That's the thing. Sorry.
This seems to be a known problem but is making use of Calc under Windows 7 nearly impossible. Continual bad allocation upon save and fatal lockups neither of which are recoverable with virtually any amount of editing of cell values in all forms of spreadsheets (small to large, single or many worksheets, a few formulas but none with refs across worksheets or spreadsheet files). To avoid you must save every few commands. This doesn't prevent the problem only limits the loss of work. I've been using the Open Office suite for many years (10+) and this is the first problem that has interfered with the productive use of Calc. Seems not to happen when using Linux based Calc on same files.
Same problem, AOO crashes when in Calc. Crash can happen at any time it seems. When using the arrow keys, or when entering data. My spreadsheet isn't complicated. Happens every few minutes, so I save often. ASUS, i7, 8G, Win 8.1
This "Bad Allocation" is affecting my productivity when using AOO4.1.1. I'm running a W7 machine with which, in all other respects I have no issues. The "BA" message appears in connection with a large spreadsheet (almost 12 Mb currently) in which I record sales data daily from my business. The spreadsheet comprises 21 pages (or sheets?) several of which cross reference others. The heart of the spreadsheet are two pages in which the daily sales records are entered from two distinct sources. These pages record data gathered over seven months; sales numbers are entered and their value calculated from item prices entered as constants at the beginning of the six months. These pages each contain approximately 2 000 rows and about 250 columns, so about half a million cells each, and consequently I guess, occupy most of the almost 12 Mb size of the whole spreadsheet. I've been trying to find what's going on through searching the web but no-one appears to have figured this out yet. As far as I'm concerned, and others too from what I read, this fault in AOO is serious. As I sadi at the beginning it is affecting my productivity - and that's ironic given the name, "Apache OpenOffice The Free and Open Productivity Suite" Is "Bad Allocation" an error from within AOO? Or, a Windows error message. If the former then presumably(?) somebody in the OO developer community knows what it takes to generate the error. It can't just appear on a whim, so to speak. So just what is going on. What's the solution?
I have created a spreadsheet template which consistently crashes AOO (including 4.1.2 on Windows 10) whenever I try to create two spreadsheets from it simultaneously. The crash occurs after CALC has loaded the template for the second time and is "calculating". Creating a new spreadsheet from the template after the crash triggers the recovery of "Untitled1" but the spreadsheet is simply a blank spreadsheet, not the one based on the template. To create the template in the first place, I made a bunch of changes to a spreadsheet, saved it, and then tried to save it again as an .ots file. That did result in a Bad Allocation message so I had to open the spreadsheet again and re-save it as a template. From what I've observed this problem has a lot more to do with the calculation engine in Calc than with save-export. Unfortunately, the .ots file is too big (>4.5MB) to attach here, but I'd be willing to send it to the appropriate AOO people if anyone can tell me how.
Created attachment 85124 [details] Spreadsheet which crashes CALC This is a cut-down version of the spreadsheet which crashes CALC when two copies are opened. Opening 6 copies of this spreadsheet on my PC will cause CALC to crash. Propagating the formulas in columns AG to AQ of the "Map" sheet, columns A to J on the "Assemble" sheet, and, A to J on the "Print" sheet to line 2000 on each sheet yields a spreadsheet which crashes CALC when two copies are opened simultaneously. Propagating the formulas beyond line 7000 causes the cursor to behave strangely and CALC to become unusable, even non-responsive. OO has to be ended via task manager. The crashes seem simply to be a result of too much storage being required to handle all the formulas in the spreadsheet.
For me, under Windows 8.1 and 10 and with OO 4.1.1 and 4.1.2, the problem seems to occur when OO is approaching the upper limit of 32-bit addressing; that is, when the total memory allocated to OO is in the 1.5 GB range. For me, the problem usually occurs after I have deleted several large sheets (350 rows x 200 columns) and then try to save. I usually can avoid the problem by deleting a few sheets, saving, exiting Calc, and starting over again.
I Have the same problem with Export to PDF It would help if at the recovery process data is sent to the developers as was done long time ago.
ok ive got the same fatal error bad allocation error, although my file is 8663.9 kb file size. and it just started doing it today. is there a fix to it? im running a budget program and have to calculate many things at once is the application. or would it be suggested to split the file into smaller parts to fix it. windows 10 pro with AOO413m1(Build:9783) - Rev. 1761381.
(In reply to mgroenescheij from comment #15) > I Have the same problem with Export to PDF > It would help if at the recovery process data is sent to the developers as > was done long time ago. Just found that a picture with 384 DPI caused the crash. Reducing the DPI whit an external utility solved the issue. It looks to me that this is an memory issue.
I keep seeing reports of this problem that I also had continuously two years ago after upgrading to 4.1. I reloaded 4.0.1 and have not had the problem since but have avoided upgrading to later releases as a consequence. In any case, I only had the problem under Windows. The problem didn't occur under Linux using the same spreadsheet files.
I am getting this error all the time now with a specific spreadsheet. Here are some of the conditions to help you fix this 1) The specific spreadsheet has a lot of sheets (around 80 or 90) 2) The specific spreadsheet has no calculated fields except SUM 3) The crash appears to only happen after one or more cut and pastes of numbers that are included in a SUM calculation. It is intermittent, but regular enough to render the particular spreadsheet unusable. Saves that occur after cutting and pasting of anything not involved in a SUM calculation does not seem to cause the error. Good luck with the fix.
Also noticed that it never happens twice in a row. It's like every three or four saves it builds up and then bursts. If you then put back the identical changes you made that you lost from a crash, it will inevitably save fine, but three or four more saves down the line and it crashes again.
I think there may have been changes to "garbage collection" between 4.0.1 and 4.1 which causes CALC to use a lot more storage than previously. I watched storage usage rise to 1.3GB then drop back to 900MB when I was creating the test case I sent along with comment 13. I haven't been able to figure out whether the problem is related to a particular function in the spreadsheets or just the number of formulas. I have some really big spreadsheets with lots of formulas which don't seem to have the problem. Anybody willing to make a 64-bit version of CALC?
(In reply to Rainer Bielefeld from comment #1) > NOT reproducible with "AOO 4.2.0-Dev – German UI / German locale > [AOO420m1(Build:9800) - Rev. 1597166 2014-05-20 1]" on German WIN7 Home > Premium (64bit)", “historic” 4. User Profile used for all predecessor > versions > > But I already saw some few times that error message with latest AOO > versions, I can't remember whether with Calc or other AOO applicatons. > > @paulstevensinoc: > We need an instruction how to reproduce your problem and a sample document. I have a very small, single sheet calc doc. It's 33k. P340 is the last entry. No complex formulae; it's a loan spreadsheet. The most common formula used is =E5-C6+D6 The "bad allocation" error began immediately after upgrade to 4.1.4. It happens perhaps 50-60% of the time I try to save this file. There are no other docs in the folder with a similar name. My computer is an Intel Core i5-3470T CPU @ 2.90GHz, with 8GB ram, on Win7 pro SP1. IF you need any other info, please let me know.
Created attachment 86300 [details] OpenOffice Calc fatal Error
Get this error randomly, doing just about anything (text entry, formatting, etc.). Do not get a chance to save, and lose any changes I have made up to that point. The document is small spreadsheet (just a reference chart, essentially) with few basic addition calculations. Open Office Version 4.1.4 OS Microsoft Windows 10 Home Version 10.0.16299 Build 16299 System Model Alienware Aurora R6 System Type x64-based PC System SKU 07DB Processor Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz, 4200 Mhz, 4 Core(s), 8 Logical Processor(s)
*** Issue 127862 has been marked as a duplicate of this issue. ***
Created attachment 86504 [details] spreadsheet-pricing Receiving the "bad allocation" shutdown failure after about 15-20 cut and paste procedures.
*** Issue 127890 has been marked as a duplicate of this issue. ***
Has anyone tried Windows Compatibility mode?
(In reply to Peter from comment #28) just tried (on the main .exe which is linked in the start bar/menu) ... - smart method: the tool concludes the best mode would be Win 8. Testing .. crashed soon. - "last environment where it worked" method -> Win XP SP3 comp mode. Testing ... seems withstanding more work though looks slowed down, also open file from e.g. browser and explorer won't work due to elevated priviledges ... anyway, 'new sheet' -> endless spinner ... then crashed. thus I would conclude such compat modes don't work, not a solution.
I do not consider compatibility mode a solution. But the theory that a compatibility issue is not hardest by your test. Would you be willing to test some more? I would like to see if 4.2.0 does change a thing. Be noted that the 4.2.0 is for other reasons not useable in daily use atm. But at least it would confirm or deny what Rainer Bielefeld has reported.
*** Issue 110361 has been marked as a duplicate of this issue. ***
(In reply to Peter from comment #30) > I would like to see if 4.2.0 does change a thing.... AOO420m1(Build:9800) - Rev. 1841506 Rev.1841506 loaded more or less usal set of calcsheets, made some editing, added some graphs ... did not take much till it crashed, without any warning/mg/popup. Working memory was some 400M according to perfmon.exe
flushed 4.x, now using 3.4.1 ... seems to work. Albeit, 32bit slow UI but at least survives usual workflow (so far)
Ok. Thanks for the hint.
Hi everybody, its the first time I wanted to report a bug. But I found this one, which fits pretty good. So I hope I don't do any wrong. I've got the same behavior of OO (portable, W10, 64bit) since an update of Windows in august 2018. Till then it worked perfect, since then it crashes more or less often, from once an hour to once in a few Minutes. I cannot find any correlation to the prevailing conditions of the system or to what I was doing in calc before the crash. It just happens so to speak. A couple of weeks ago I tried different versions of portable OO4.15 (selfmade, portableApps and winpenpack). The behavior of all these was basically the same. Then I changed to 4.16 (AOO416m1(Build:9790) - Rev. 1844436 2018-10-23 12:57). For a couple of days it worked fine (NO crash at all). But then, again after an update of W10, the crashing-issue came back. Sometimes it crashes just ro restart instantly, sometimes it crashes with "bad allocation" message and vanishes completely...again, no clue why sometimes so and sometimes so.
Not that I want to be too optimistic, but with an W10 Update 2 days ago, it seems something good has happend, at least concerning OO4.16. Since then I worked pretty intensively for at least 12-15h with numerous spreadsheets which crashed regulary before: Not even one crash since this last W10 update. Merry Christmas and a peaceful 2019
Update on my side too after #c36 ... Given a try to 4.1.6, seemed (more) stable but same very annoying slowness as 3.4.1 I'm using. Though at some point it crashed with no msg / clue opening a trivial latin1 .csv (bank transactions). 'slowness' means: click-dx on a cell ... 1s ... 2s ... 3s ... finally context menu pops up. Same with many/most other actions on menubars / on context. Re-tried 4.1.5 then (was there while reporting #127890), same thing as 4.1.6. Seems the OS build makes the differences then, now it's: OS: Win 10 Pro 1809 27.5.18 build 17763.253 dted 17.11.18 but +latest patches. Seeing no gain, rather perhaps a somewhat worse stability, I'm reverting to 3.4.1 for now. BTW looks like the AOOo win binary is 32 bit only, no 64bit binary available? thx
(In reply to oopla from comment #37) > 'slowness' means: click-dx on a cell ... 1s ... 2s ... 3s ... finally > context menu pops up. Same with many/most other actions on menubars / on forgot to note, that's on 1st use of a function(ality), then no delay on further usages at least for some time or some number of different functions used
Status on Win 64 Conversion (And anything not specific to the solution of bugs) is better asked directly on dev mailing list. Simply send a mail to dev@openoffice.apache.org. We are actively working on 64bit version. How much rows and lines does your cvs file have?
Calc AND Impress are constantly crashing on Windows 10 64 bits Home and Pro version 1803, since at least update KB4023057 (update released in Feb. 2019 to prepare PC's for Windows 10 version 1809), and probably since the earlier update KB4487017. It has continued on Windows 10 Pro version 1809. It affects AOO 4.1.13 to 1.16. My systems have 4 to 8 GB RAM, with Core i7 and i3 processors, and essentially unlimited available disk space, so it's not a hardware issue. This is a very urgent issue to be solved if OO is to remain usable on Windows 10. ALL of my .ods spreadsheets and .odp presentations are crashing, regardless of contents (objects, charts, figures) or file size. Please look into it. It's not related to some files having issues, it's related to OO not being compatible with recent changes to Windows 10. LibreOffice is not having these issues.
Checking the Windows Event Viewer, I found the following repeated error messages, related to OpenOffice Calc crashes: Faulting application name: soffice.bin, version: 4.0.9790.500, time stamp: 0x5bcf995a Faulting module name: sal3.dll, version: 4.0.9790.500, time stamp: 0x5bcfc1cf Exception code: 0xc0000005 Fault offset: 0x00004a0c Faulting process id: 0x30dc Faulting application start time: 0x01d4e67db92a070e Faulting application path: G:\Program Files (x86)\OpenOffice 4\program\soffice.bin Faulting module path: G:\Program Files (x86)\OpenOffice 4\program\sal3.dll Report Id: 6deada83-c9a3-4566-810d-2c7b6ab46903 Faulting package full name: Faulting package-relative application ID (error repeated 11 times in ONE hour) Faulting application name: soffice.bin, version: 4.0.9790.500, time stamp: 0x5bcf995a Faulting module name: tl.dll, version: 4.0.0.500, time stamp: 0x5bcfc1d0 Exception code: 0xc0000005 Fault offset: 0x0004a277 Faulting process id: 0x18a0 Faulting application start time: 0x01d4e4265bf4bd2f Faulting application path: G:\Program Files (x86)\OpenOffice 4\program\soffice.bin Faulting module path: G:\Program Files (x86)\OpenOffice 4\program\tl.dll Report Id: d322a820-a2bb-46e9-acfb-385bdaf7141e Faulting package full name: Faulting package-relative application ID: (error repeated 1 time in ONE hour) Faulting application name: soffice.bin, version: 4.0.9790.500, time stamp: 0x5bcf995a Faulting module name: MSVCR90.dll, version: 9.0.30729.9518, time stamp: 0x5b690a0f Exception code: 0xc0000005 Fault offset: 0x0003ae7a Faulting process id: 0x21a4 Faulting application start time: 0x01d4e4e6d1e691e1 Faulting application path: G:\Program Files (x86)\OpenOffice 4\program\soffice.bin Faulting module path: C:\WINDOWS\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.9518_none_508db366bcbd18c4\MSVCR90.dll Report Id: c9d2fd64-f820-4a71-bdb3-3ca029b9f1ba Faulting package full name: Faulting package-relative application ID: (error repeated 3 times in ONE hour) Total: 15 crashes in one hour of using Calc.
Also getting the Fatal Error... "bad allocation" in 4.1.7 when copying part of one sheet to a new one. I was using 4.1.6 yesterday and getting an identical result.
This error in calc has been around for 5 years. Why won't someone fix it. It is a fatal error causing all that you have entered to be lost. Unless no one is responsible for fixing severe bugs this error should have been fixed by now. IT IS A DISGRACE.
Not sure if this was just luck, but error finally stopped for me after I moved spreadsheet from an external drive to the C drive. I was constantly getting 'bad allocation' followed by crash whenever I saved and other times - probably when auto-saved. (Calc 4.1.10 and 4.1.5 on Win 10) Spreadsheet is small and simple but was stored on a thumb drive. Moving it to the C drive SEEMS to have stopped the errors, at least for now.
AOO v4.1.13 on Windows 10. Unfortunately, the issue of bad allocation in Calc, causing crashes and data loss, persists.
Firstly, as per OpenGrok, the text "bad allocation" doesn't seem to come from anywhere in our code. It's likely returned from a Windows library, perhaps in response to a bad_alloc exception that would be thrown when memory cannot be allocated, either because you're out of RAM, or the code (wrongly) requested a huge amount of RAM that can't be allocated. It is a bad sign, that the "Faulting module name" differs. Possibly, RAM running out in different places, or depletion of the i386 4 GiB RAM limit, but 4 GiB is still a lot of RAM, why does it run out, do you have many documents open or a huge document open, or is OpenOffice leaking memory? People reported only a few hundred MB RAM in use, so maybe it's not RAM running out, maybe it's a buggy, huge allocation request that cannot be satisfied? Why is it huge? Some calculation error due to memory corruption? :( I'll try reproduce this when I have some time. Unfortunately people say the bug doesn't occur on Linux, where debugging this would be easiest. But if so, then at least you have a workaround - use OpenOffice on Linux until this bug is fixed. Oh and since earlier versions worked, this is a regression: marking it as such.
Hi Damjan, I work on a Windows 10 Pro laptop with a 1TB SSD and 8 GB of RAM. I get bad allocation errors in a number of ODSs, they tend to be bigger in size. For instance, I'm currently editing an ODS, 80 KB in size, containing 6 sheets with a mixture of text and formulas. There is not much going on in Windows background, just 5 other applications opened. And the document keeps crashing, throwing bad allocation errors. I also work with Writer a lot on the same computer, the files are much bigger and no bad allocation errors. This issue seems to occur specifically in Calc.
I can reproduce this with the big spreadsheet attached here (https://bz.apache.org/ooo/attachment.cgi?id=85124), by copying all columns in the range A to AQ of the "Map" sheet (select the column headers then copy), and pasting them into a new sheet, and repeating this several times. Each new sheet they are pasted into increases memory usage by several hundred MB, and when RAM usage nears 2 GiB, the "bad allocation" messagebox briefly comes up, then OpenOffice silently exits (probably as even the recovery attempt crashes separately). Changing status to CONFIRMED. Now this spreadsheet is big, but it's not that big. Why is so much memory being used? Was it being used in older versions of OpenOffice? Maybe not. On bug 124064, the poster gave specific SVN versions which exhibited the problem. One of the bad versions was 1530680, which is now Git commit 58a710212d90860fe18cdb22f67014b5297207e1, and one of the good versions was 1516435, which is now Git commit 334aff22543c984093b19f3d62460864ecb687cc. It should be possible to "git bisect" this range of 111 commits, and find the patch that increased memory usage. I still do advise using a 64 bit version of OpenOffice until this is fixed, available on Linux, Mac, and FreeBSD, as it will at least allow you to use all the memory on your computer and significantly postpone the crash, not limit you to 2 GiB and early crashes like the 32 bit version on Windows.
I'm glad to see this is now confirmed. It has been around at least since 4.1.2. If you want a simpler way to cause the crash and can tell me how to send them to you, I'll send a couple of bigger Crash.ods files which cause the error when you try to open them together. As for the suggestion to use a 64 bit version of AOO, is there one in the works for Windows?
(In reply to RonBlackwell from comment #49) > I'm glad to see this is now confirmed. It has been around at least since > 4.1.2. If you want a simpler way to cause the crash and can tell me how to > send them to you, I'll send a couple of bigger Crash.ods files which cause > the error when you try to open them together. Thank you, I'll let you know. > As for the suggestion to use a 64 bit version of AOO, is there one in the > works for Windows? I was working on it some years ago, and hope to carry on soon, but it's long and difficult. Progress is tracked on issue 46594 and this Wiki page: https://wiki.openoffice.org/wiki/Win64_port
I managed to build commit 334aff22543c984093b19f3d62460864ecb687cc (with lots of backporting patches as per https://wiki.openoffice.org/wiki/Building_old_versions), and while it still errors out when memory runs out, it gives different errors: assertion failures instead of "bad allocation". Let me try build 58a710212d90860fe18cdb22f67014b5297207e1 and if it gives "bad allocation", start a git bisect.