Description: Performing a large operation (such as selecting and copying and pasting thousands of rows from one worksheet into another worksheet) in a large Calc spreadsheet will seem to work fine but will lead to a Bad Allocation crash when attempting to save the modified spreadsheet. The attached files demonstrate the problem. Steps to Reproduce: 1. Using attached file ProblemDemo.ods, go to the sheet named Orig Price Data 2. Enter cntl-A to select the entire sheet (~4000 records in use) 3. Enter cntl-C to copy the entire sheet 4. Go to the blank sheet named Pared Price Data 5. Enter cntl-V to save all copied data 6. Enter cntl-S to save the entire spreadsheet to disk 7. Wait while this operation proceeds: takes many minutes on my little Acer 8. When the Bad Allocation error occurs, click on OK and watch Calc crash Actual Results: Calc exits memory. The next time it is used, it asks if you wish to restore the above file, but nothing is there to be restored, so you are right back where you started -- all of your extensive changes are gone. Expected Results: It should save the file properly, of course. If that is somehow impossible, it should at least warn you and continue running so that you have a chance to copy your changes (perhaps just one or two of many worksheets) to a different file. Reproducible: Always User Profile Reset: Yes Additional Info: I am seeing this problem A LOT over the past few days (since 25 November 2019). I have two large files that I can send to you that should help in isolating the problem. I will attach them to this form. One of the files is a text version of the Windows 10 System Information (about 0.8 Mbytes) so you can see the specifications of my computer and the Windows 10 version number and all of those things. The other file is an actual spreadsheet file (.ods file) that causes the problem very consistently. It is about 26 Mbytes. I have spent a lot of time using LibreOffice Calc over the past few years. About nine months ago I installed LibreOffice 6.1.5 and used it up until this week creating a dozen or so *large* spreadsheets with file sizes of 180 Mbytes or more. These are slow to load and slow to save, but other than that they *had* been working fine. Suddenly that all changed this week. I cannot seem to do the simplest operation in any of those large files without getting a Bad Allocation error message when I try to save my changes. I started all over on a new file and gradually built it up to be very much like my other files. When it reached about 20 Mbytes in size, I started getting the Bad Allocation error. It has lots of tabs (lots of sheets) but in particular it has two named Orig Historical Price Data and Orig Historical Cap Data. The first of these two contains almost 4000 records. I would like the second of these two to be an exact copy of the first (as a starting point for my work). However, I can only copy a few hundred records from one to the other and still save the changes. If I copy thousands of records from one to the other, then I get a Bad Allocation message when I try to save the changes. I tried running in Safe Mode (as recommended in "instructions for resolving User Profile corruption" and the problem still happened. I tried running with OpenGL disabled and the problem still happened.
I installed Version 6.3.3.2 (x86) and the problem still happens. I added 8 Gbytes of "ReadyBoost Memory" to Windows 10 and the problem still happens.
Created attachment 156210 [details] Screen shot of Bad Allocation error message
Created attachment 156211 [details] Windows 10 System Summary for my poor little Acer Aspire One laptop
Having trouble transferring the large spreadsheet that reproduces the problem. I only have 1 Mbit/sec internet service. Why does the transfer time out after only 2 or 3 minutes?
The word "Historical" does NOT appear in the names of the tabs mentioned in part of my description. The names are simply "Orig Price Data" and "Orig Cap Data" -- I got them right in one place and wrong in another. Sorry.
Created attachment 156212 [details] ProblemDemo.ods MarvinWWW e-mailed me this sample, and asked me to attach it.
> I installed Version 6.3.3.2 (x86) and the problem still happens. I guess, this is related to the 2GB memory limit for x86 processes. During save, i noticed memory consumption goes up from ~500MB to ~1.8GB with LO 6.3.3.2 x64. The memory is released after saving is done.
confirm in Версия: 6.4.0.0.beta1 (x86) ID сборки: 4d7e5b0c40ed843384704eca3ce21981d4e98920 Потоков ЦП: 4; ОС:Windows 10.0 Build 17763; Отрисовка ИП: GL; VCL: win; Локаль: ru-RU (ru_RU); Язык интерфейса: ru-RU Calc: threaded 32 bit only problem
Thanks Aron Budea for attaching the large ProblemDemo.ods file for me! The Bugzilla website kept timing out when I tried the transfer, but the Microsoft Office Outlook application waited patiently for the entire file to be transferred as part of my email to you.
I am new at this. Is there any kind of schedule for correcting a problem like this? ALL of my spreadsheets of interest are MUCH larger than ProblemDemo.ods, so I am really stuck. The spreadsheets were ALL working fine earlier this year, but now I can only look at them. I cannot compute anything new -- that is, I cannot save the results of any new computations. If no one can give me any kind of a schedule, then I might have to go buy a 64-bit computer in order to get my project back on track... I am really not trying to be pushy, but I do have a big decision to make -- about buying a new computer -- based on this problem. Please advise!
(In reply to MarvinWWW from comment #11) > If no one can give me any kind of a schedule, then I might have to go buy a > 64-bit computer in order to get my project back on track... This is a volunteer-driven project, so there's no particular schedule for random bugs. If you're going to buy a computer in the end, you should try your workflow first on a similar machine to make sure it works. Typically when processing a file takes up a lot of memory, the user experience while working on the file could be subpar (at least loading/saving). If possible, splitting up the data into multiple spreadsheets sounds like a good idea.
Aron: Thanks for your reply. I kind of THOUGHT there would be no fixed schedule. I figured I should ask, though, since this bug causes a crash and loss of data. I thought it might be assigned a higher priority. Oh, well. I went online and found two fabulous deals on refurbished 64-bit machines. One has an Intel I3 processor plus 4 GB of RAM. The other has an AMD processor plus 4 GB of RAM. I will try both.
Dear MarvinWWW, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I got out my little OLD Acer computer on which I first noticed this problem. I loaded LibreOffice 7.2.5 on it. I tried working with one of the large spreadsheets that always caused the problem reported in this Bug Report. I could not reproduce the problem. The spreadsheet seemed to work fine while running LibreOffice Calc, and it seemed to Save to disk in normal fashion when I was done.