(In reply to gzernmplatz from comment #3)
> (In reply to MM from comment #1)
> > (In reply to gzernmplatz from comment #0)
> > > Description:
> > > Attached spreadsheet has 643202 lines and 9 columns. When I select 643201
> > 
> > Which attached spreadsheet ???
> 
> Sorry, I wasn't yet able to attach it. I will try to zip it. Is the
> replacement helpful?

No, we don't have time to build stuff in order to test bugs. You could use http://wikisend.com/ to give us the file

For reference, the contents of the attached text file:
Tried to attach file several times but failed and saw it is bigger than size limit. How to make similar file:
1. New Spreadsheet
2. Input some letters as captions in the first line, first 9 columns
3. Under that, get some natural numbers in the range 10 to 28 in the first 8 columns until line 643202 - you could use random numbers, for example.
4. cell I2, input the formula:
=WENN(I2=A2;1;0)+WENN(I2=B2;1;0)+WENN(I2=C2;1;0)+WENN(I2=D2;1;0)+WENN(I2=E2;1;0)+WENN(I2=F2;1;0)+WENN(I2=G2;1;0)+WENN(I2=H2;1;0)
5. Select until end of file and fill, so the formula is in the whole 9th column
Hope that works. I will try to zip my file and attach it - I guess its size is the reason for the crash, because I keep getting crashes with big spreadsheets.

You can download the spreadsheet from
http://wikisend.com/download/839820/mitB2.ods
I'm sorry for messing it up. By now I also have a zipped version that is under the size limit but zipped in Linux. Would it be useful to attach it?

Unconfirmed with v5.2.5.1 under ubuntu 16.04 x64.
Confirmed with v5.2.5.1 under windows 7 x64.

Hangs for some time with ubuntu, but no crash. Seems windows only ?!
All cells without the IF's don't hang, copied fast.

Created attachment 130698 [details]
Big spreadsheet zipped

I cannot reproduce the crash on my Win debug build. The spreadsheet becomes normal after Ctrl-C and waiting for a moment. Using laptop from 2012 with 8GB mem and i7 CPU.

Win 7 Pro 64-bit Version: 5.4.0.0.alpha0+
Build ID: 1c27286b9d5331634c073cd3e327bd941e61bbb6
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2017-01-23_03:24:17
Locale: fi-FI (fi_FI); Calc: group

Created attachment 130699 [details]
WinDBG

I did get a crash with: http://wikisend.com/download/839820/mitB2.ods
However: I did accidentally clicked a cell while the copying process was going on

Version: 5.4.0.0.alpha0+
Build ID: c2850bab4f7e5700151a18d806268f2b86a25d56
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2017-01-24_03:10:33
Locale: nl-NL (nl_NL); Calc: CL

Created attachment 130790 [details]
Two WinDBG Backtraces

Two additional backtraces when using copying an waiting

Version: 5.4.0.0.alpha0+
Build ID: c2850bab4f7e5700151a18d806268f2b86a25d56
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2017-01-24_03:10:33

i have no crash with big spreadsheet mitB2.ods
loading takes a while also copy I column takes some time
pasting to another column takes time also saving the file

Version: 6.0.0.0.alpha0+
Build ID: 18909d45977a897cbd921d76d1dde4bf3a466271
CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: kde4; 
Locale: nl-BE (en_US.UTF-8); Calc: group

Created attachment 134713 [details]
test case - first needs to be expanded

This spreadsheet can be used for testing by first filling the columns (ctrl-d). I can't upload a complete version because my attempt to produce it made my LO crash.

This bug seems to be very sensitive to file size. When I deleted about half the lines of the spreadsheet it was gone afterwards. So I ask you to do the following steps: 
Load rand1.odt
select the stuff inside
press ctrl-shift-ArrowDown
press ctrl-d
If this does not make your LibreOffice crash, now you have a bigger spreadsheet than mitB2. You can of course fill a few columns to the right, too. Could you please try this and tell us wether the bug occurs?

It is clearly due to running out of memory. I have 32 gigabytes of mem and I could even fill right all the way to column O.

Does the crash ever happen, if you set the undo steps to 1 in Tools - Options - LibO - Advanced - Expert config: org.openoffice.Office.Common/Undo ?

Yes, it does. In some cases it says "Bad Allocation", in some it just says LO does no longer work due to a problem. Furthermore, I loaded the file and did not make any changes to it before trying to copy. Instead of crashing, LO could just say something like "can't do that because memory runs out".

test with rand1.odt  no crash, have only 8gig of memory, use only 3.5 gig
saving the file very slow

Version: 6.0.0.0.alpha0+
Build ID: 98782932280d20ece450fa06a90c202fb8e2a26e
CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: gtk3; 
Locale: nl-BE (en_US.UTF-8); Calc: group

calculate very slow takes 5 times more than with

Version: 5.3.4.2
Build ID: SlackBuild for 5.3.4 by Eric Hameleers
CPU Threads: 8; OS Version: Linux 4.9; UI Render: default; VCL: kde4; Layout Engine: new; 
Locale: nl-BE (en_US.UTF-8); Calc: group

LO 6.0 alpha 32-bit - Win 7 64-bit:
1st try: LO had dump on fileopen (seen with procdump)
2nd try: LO didn't crash on copy from Description but there was dump on copy (seen with procdump)
3nd try: LO consumes 1 GB on fileopen. Used 1,6 GB on copy and than crashed, document recovery, no crash report.
So I can confirm crash, but cannot confirm crash is about running out of memory. Even saving file stayed at 1 GB, although it was rather slow. 

Telesto had:
FAULTING_SOURCE_LINE:  c:\cygwin\home\tinderbox\master\sc\inc\formulacell.hxx
SYMBOL_NAME:  sclo!ScFormulaCell::GetMatrixFlag+a
and
FAULTING_SOURCE_FILE:  c:\cygwin\home\tinderbox\master\include\formula\token.hxx
SYMBOL_NAME:  forlo!formula::FormulaToken::IncRef+12
I had on load:
SYMBOL_NAME:  sal3!osl_acquireMutex+f
and on crash:
SYMBOL_NAME:  sclo!ScMatrix::IsValueType+79c1
and on Comment 13 (that's not really clear) select:
SYMBOL_NAME:  sal3!rtl_allocateMemory+65

Bad allocation in 6.2+.

Dear gzernmplatz,

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 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug