My calc-file is about 40MB big, there are some tables and each of them has more than 100.000 rows. Libre Office crashes after I delete a table and try to work with remaining data (somtimes the tab with the tablename remains after deleting, some more graphical errors - white rectangles,... apear before crash) Error also happens after i copy a cell with a formula to the remaining 100k+ cells below. In both cases I am able to delete one table, or copy the cells one time and save the document. After this the crash happened allways Exact time when Libre Office crashes depends on activity: at saving, at deleting another table, at copying another column formulas,... best regards
If you don't provide any more information, I'll be forced to close this bug as invalid. You need to help us reproduce the bug. A sample file is a minimum to provide here, but a backtrace of the crash would help a lot. Please read: http://wiki.documentfoundation.org/BugReport
Sorry, I had to change data because of copyright and was in haste while filing the bug. As the example-file is to large, i provede the download from http://dl.dropbox.com/u/12755058/example_file.7z Reproducing crash: *) Open File *) Table3: mark Range A2:N2, copy *) mark Range A3:N678257, paste Libre Office also crashes when copying in 100k steps A3:N100000, paste A100001:N200000, paste --> crash My System: Windows7 - 64bit 4GB RAM LibreOffice 3.3.0 (32bit)
Kohei, this is yours. I could see huge memory increase during the paste... but it didn't crash. But may be that the insane amount of memory on my machine that prevented it.
Marking this as a perf (memory footprint) issue. The crash is likely caused by too much allocation based on the comments so far.
(In reply to comment #2) > As the example-file is to large, i provede the download from > http://dl.dropbox.com/u/12755058/example_file.7z Hmm that file is no longer available. Could you post it again?
I need to get the document from the reporter once again. The dropbox link is no longer working.
Hi Sorry for the delay. I posted the file again on dropbox - the new url is http://dl.dropbox.com/u/12755058/example_file.7z
Thanks. This time I've mirrored it in my home directory to avoid losing it again. http://people.freedesktop.org/~kohei/fdo/34777/example_file.7z
Ok. The cause for the crash is excessive memory usage. We may or may not be able to solve this short-term, since part of that is a design issue. We probably need to change a lot of places to allow documents this large to be editable without consuming a lot of memory. Let me dig into this to at least identify the problem areas.
I am also experiencing this with files from 11,000 to 80,000 rows.
I appreciate this may not be the most useful bug report... Performance on Mac OS X with latest release, is actually worse now with medium/ big spreadsheets crashing regularly, that worked in earlier versions (4.1.4). Data is sensitive so I cannot provide sample file, but has 7 sheets, each ~10 columns and ~2000 rows... Version: 4.2.0.2 Build ID: 125e3e788aa207ab80b6f39e74ef57af7e2129b6
Hi there, I'm having the same problem, working with big files becomes really painful if you have many other programs running including other LO files as well (chrome with a lot of tabs for instance). walli2 had the crash while copying and pasting, i have them while introducing a formula (=si(buscarv(xx)... crashed). This wasn't so visible on previous releases but with the arrival of 4.1.4, working with big files has become really hard. I'm running win 7 x86 with 2 GB of RAM
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (4.4.1 or later): https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-07-18
Didn't crash here with A3:N678257, paste, but I have 8GB of memory. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: fcc2415ade6ae93710bbbda9f7e163045e323105 TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-10-21_16:55:13 Locale: fi-FI (fi_FI)
Created attachment 119895 [details] Example file
Migrating Whiteboard tags to Keywords: (perf) Importance seems pretty low (medium/normal) for a confirmed crasher, eh?
The 32-bit Windows version can easily run out of memory for large data amounts, there's ~nothing we can do about. One can try to limit Undo steps to 1 or even disable Undo, as holding Undo information for large data changes needs additional memory for each step. Other than that use the 64-bit version instead (which wasn't available back when the bug was reported but now is) and have enough RAM.