Bug 79138 - Calc crash on large selection Delete
Summary: Calc crash on large selection Delete
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected) release
Hardware: All Windows (All)
: high major
Assignee: Not Assigned
Depends on:
Blocks: AutoSave-AutoRecovery-Backup
  Show dependency treegraph
Reported: 2014-05-23 15:53 UTC by Luuk
Modified: 2019-06-19 07:39 UTC (History)
3 users (show)

See Also:
Crash report or crash signature: ["ScFormulaCell::SetDirtyVar()"]
Regression By:

bad allocation (67.89 KB, image/png)
2014-05-23 15:53 UTC, Luuk
test4242.ods (13.35 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-05-25 10:56 UTC, Luuk
screenshot of error in LO5.1 (74.37 KB, image/png)
2016-02-21 15:34 UTC, Luuk

Note You need to log in before you can comment on or make changes to this bug.
Description Luuk 2014-05-23 15:53:33 UTC
Created attachment 99661 [details]
bad allocation

when selecting a lot of cells, and deleting them calc crashes (somtetimes)
with the text 'Bad Allocation'
(see attachement)
Comment 1 Joel Madero 2014-05-24 22:06:55 UTC
When you say "deleting them" do you mean deleting the content or the columns? Also "sometimes" - can you be more specific? Also, what is your operating system and is this a new problem which you don't see in release?

marking as NEEDINFO - please give us a bit more detail and then mark the bug as UNCONFIRMED. Thanks!
Comment 2 Luuk 2014-05-25 10:55:25 UTC
What i tried to do was:
"Find out if a long (in time) operation would influence the Autorecovery"

What i did was:
1) I created an calc-sheet  (see attachment test4242.ods)
2) I copied cells A3:C3
3) I pasted them to: A4:A1048575
4) Then i pressed Ctrl+Home to get back to the top of my sheet
5) I selected: A4:C1048575, and pressed the 'Delete'-key

On 1 of my attempts to do this, i received the 'bad allocation' error.
On other attempts, i was not able to save the document after step 5
(Resulting in I/O errors, which i have not copied...)

I know that (especially step 3) seems a pretty useless action, But these steps should not be the cause of a problem when working with a calc-sheet.

Finally, after Joel's comment, i tested this with, and same thing go wrong in this version. (It's not a new bug for 4.3 )
Comment 3 Luuk 2014-05-25 10:56:06 UTC
Created attachment 99759 [details]
Comment 4 Luuk 2014-05-25 10:57:38 UTC Comment hidden (obsolete)
Comment 5 Joel Madero 2014-05-25 17:22:10 UTC Comment hidden (obsolete)
Comment 6 ign_christian 2014-06-10 04:49:49 UTC
I got similar results with (Win7 x86) :

(In reply to comment #2)
> 3) I pasted them to: A4:A1048575
Freeze after that step, about 10 secs

> 5) I selected: A4:C1048575, and pressed the 'Delete'-key
Freeze then crash

Looks those operations consume high resources.
Comment 7 Joel Madero 2014-06-10 04:52:11 UTC
Based on last comment marking as NEW and updating version
Comment 8 QA Administrators 2016-02-21 08:35:19 UTC Comment hidden (obsolete)
Comment 9 Luuk 2016-02-21 15:33:25 UTC
First of all, since reporting this bug, some things changed

1) I upgraded Windows 7 to Windows 10
2) I decided to run the 64-bits version of LibreOffice
3) Currently running (x64)

The problem still exists (see screenshot)

I also changed the number of columns I am copying/pasting to 9,
so i change the range in step 3 from A3:C3 to A3:I3  (after putting some values in those columns) and changed the range in step 5 from A4:C1048575 to A4:I1048575

Another thing that might be necessary to get this behavior is changing this:
Tools/options/Load/Save/General 'Save Autorecovery every: 1 minutes'
Comment 10 Luuk 2016-02-21 15:34:26 UTC
Created attachment 122851 [details]
screenshot of error in LO5.1
Comment 12 QA Administrators 2018-05-24 02:46:10 UTC Comment hidden (obsolete)
Comment 13 Timur 2018-06-18 16:47:57 UTC
Bad allocation repro with libo-master~2018-06-18_00.55.07_LibreOfficeDev_6.2.0.0.alpha0_Win_x86.msi
Comment 14 QA Administrators 2019-06-19 02:47:26 UTC Comment hidden (obsolete)
Comment 15 Luuk 2019-06-19 06:40:45 UTC
Because i bought meself a new computer since the days i reported this bug,
and because this computer is more powerrfull then the previous one,
and because this 'bug' is about operations which takes long time (longer than 1 minute, to overlap time set in 'Save autorecovery information every .. minutes')

and because this was reported for version 4.0, and currently we have 6.2,

I do net see any advantage in trying to reproduce this in version 3.3.

Because all of the above, I am suggesting to close this bug (WONTFIX?), which leaves you all to solve bugs which will need more attention, unless 'lots-off-people' are facing issues because of this bug... 😊
Comment 16 Xisco Faulí 2019-06-19 07:39:03 UTC
Thanks for retesting with the latest version.
Setting to RESOLVED WORKSFORME as the commit fixing this issue hasn't been identified.