Description: Bad allocation crash while saving Steps to Reproduce: 1. Open attachment 150858 [details] 2. Select columns ABC & Copy 3. Add a new sheet & paste (repeat 3 times) 4. Press Save -> BAD alloc Actual Results: Crash with BAD Alloc (x86) Expected Results: No crash, similar to 4.4.7.2 Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 6.4.0.0.alpha0+ (x86) Build ID: 93477d1a963e38e3319013e43835a8ffef200972 CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-06-02_10:16:52 Locale: it-IT (nl_NL); UI-Language: en-US Calc: threaded but not in Versie: 4.4.7.2 Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Locale: nl_NL
Not reproduced in Version: 6.3.0.0.beta1+ Build ID: 4abdaf4afb2245d404f6709124b3c627b07b8a3c CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded win only ?
(In reply to Xisco Faulí from comment #1) > Not reproduced in > > Version: 6.3.0.0.beta1+ > Build ID: 4abdaf4afb2245d404f6709124b3c627b07b8a3c > CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; > Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US > Calc: threaded > > win only ? I think so.. And x86 only.. I guess it's some kind of OOM issue. Seems the most probable (looking at memory usage of x64 build compared to x86). However happening somewhere out of sight. Process explorer suggests mem usage of 800 MB. Crashing normally starts at 1,2 GB Moggi would opt for: this is only sane thing to do :-). However this did work in the past.. Not sure how large the x86 community is :-) Slightly off topic: when do we get Windows x64 bibisect builds instead of x86.
repro 6.4+
it took a while to bisect. Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=aa44e10942937452930255be156c1b29247ee969 author Luboš Luňák <l.lunak@collabora.com> 2019-05-25 12:28:27 +0200 committer Luboš Luňák <l.lunak@collabora.com> 2019-05-28 12:28:01 +0200 commit aa44e10942937452930255be156c1b29247ee969 (patch) tree db5258343c82c434d1026870285ae9f21727f915 parent 7cd3f267cfbf3655f6a7a395b80560ecd22e15f7 (diff) parallel deflate compression (one stream, multiple threads) Bisected with: win-6.3 Adding Cc: to Luboš Luňák
I am also 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, but I do not quite see how to 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 15 Mbytes. I only have 1 Mbit/sec internet, so I do not want to attach the files incorrectly and waste a lot of time, then find out that I have to start again. For now, I can tell you that 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 15 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.
MarvinWWW: your bug sounds different, please open a new bug report, and attach the samples you have.
(In reply to Aron Budea from comment #6) > MarvinWWW: your bug sounds different, please open a new bug report, and > attach the samples you have. Aron: OK. I will try. I have A LOT of software maintenance experience, but I have never used Bugzilla before.
@Xisco, Is it possible for you to confirm that the patch @ https://gerrit.libreoffice.org/c/core/+/84394 fixes the problem in Windows x86 (32 bit) ? At the moment I could only test this on Linux by imposing an artificial 2GB memory limit and it work there correctly. Thanks in advance !
Dennis Francis committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0b8ae8725083eb0526a262d434cc06fb3f3e7336 tdf#125662: disable parallel-zip if the memory... It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dennis Francis committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d98cc8f881673f64f0a1fa35eea8610fb5b083e3 Revert "tdf#125662: disable parallel-zip if the memory..." It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dennis Francis committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/353d4528b8ad8abca9a13f3016632e42bab7afde tdf#125662: do parallel-zip in batches It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Fixed in master branch. Backports pending.