Download it now!
Bug 125662 - Bad allocation crash while saving Calc with copied columns (x86)
Summary: Bad allocation crash while saving Calc with copied columns (x86)
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.3.0.0.beta1+
Hardware: All Windows (All)
: high major
Assignee: Dennis Francis
URL:
Whiteboard: target:6.5.0
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Memory
  Show dependency treegraph
 
Reported: 2019-06-03 16:51 UTC by Telesto
Modified: 2020-01-13 16:56 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2019-06-03 16:51:35 UTC
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
Comment 1 Xisco Faulí 2019-06-04 11:53:46 UTC
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 ?
Comment 2 Telesto 2019-06-04 12:20:37 UTC
(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.
Comment 3 Timur 2019-06-05 14:37:18 UTC
repro 6.4+
Comment 4 Xisco Faulí 2019-06-06 09:27:10 UTC
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
Comment 5 MarvinWWW 2019-11-29 07:02:49 UTC
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.
Comment 6 Aron Budea 2019-11-30 02:54:19 UTC
MarvinWWW: your bug sounds different, please open a new bug report, and attach the samples you have.
Comment 7 MarvinWWW 2019-11-30 23:30:58 UTC
(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.
Comment 8 Dennis Francis 2019-12-30 10:56:36 UTC
@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 !
Comment 9 Commit Notification 2020-01-04 06:58:42 UTC
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.
Comment 10 Commit Notification 2020-01-13 11:10:35 UTC
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.
Comment 11 Commit Notification 2020-01-13 11:12:36 UTC
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.
Comment 12 Dennis Francis 2020-01-13 16:52:26 UTC
Fixed in master branch. Backports pending.