Created attachment 134839 [details] sample file steps: 1) select cells A1 to A7 2) press CTR+X (cut) 3) click on the D column (the top, before any cell), it will select the whole column 4) press CTR+V (paste) 5) It crashes
Reproduced in Version: 6.0.0.0.alpha0+ Build ID: bde72cdae1e7e001d5089c5284672c976b8e43df CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group and in Version: 6.0.0.0.alpha0+ Build ID: a9588baca8137f51e2ca72e40b1f448b0e1885d1 CPU threads: 1; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@39, Branch:master, Time: 2017-07-21_03:03:23 Locale: es-ES (es_ES); Calc: group
in Version: 4.2.0.0.alpha1+ Build ID: fc8f44e82de4ebdd50ac5fbb9207cd1a59a927e3 it freezes, while in Version: 4.1.0.0.alpha1+ Build ID: a2c9d4f8bbde97f175bae4df771273a61251f40 it takes one second. it needs to be bisected with bibisect-42max
That's a user mistake. If you paste some cells to a whole column, it will paste them a number of times until it fills row 1.048.576. So it's rather slow, for me both in master and 5.3. Looks like hang because of "Not responding", but I don't get crash, if I wait. No bug for me here as described. I don't understand what's the "crash" you experienced and is there any crash report.
/bibisect-42max$ 8e7bade4e7314a340c77edd9042e230f61f0323d is the first bad commit commit 8e7bade4e7314a340c77edd9042e230f61f0323d Author: Matthew Francis <mjay.francis@gmail.com> Date: Sat Sep 5 18:33:36 2015 +0800 source-hash-4c99a427ee4adaeddb2682c192384bad21d9d09b Bibisect: This commit covers the following source commit(s) which failed to build c7bdee8dbd1cf260a8513a0d31b36f90daa70f1c 77ec47356025de4e46f48f94629f896349b0a8e5 e9c5eb60d53204261c7937108bd53e86e46fc2f3 75dec25730c88bdb8eb5e2a3f92689460fa89d29 c008dc483f8c6840803983e7e351cec6fdd32070 46419cd7a2d453c6f252c28dfb9dbfb08605e1c4 dcf04c58456d8285bdcaa2921b6c08d48e09dab3 dabeb3d643c0ebd2cb7fdce333d0e6248b1488ad 8b252f30267d043522ff2cbf2bf42275bb7a6ec6 76ca1529edb9afdb1838ab9a9e01fa231148c1d8 341a4c87e977a2fd3948de6eaa647be4b32e6ebc 3b3b0c04385851f120dc26d26e40f0d1c6344274 cb4a47887df282196c9aa529269d5115306813c1 1fe76b401760e0b31095d0a4d7e877aeee1624dc 6ea53929245eb496d6954ab266636978653f1784 65be1e27254ff1292b3593af42fbfb0235c26fcd b6a6a26698cb56a194c7c99b0ad267e60e3a05d5 3b0c069c9a157c4cd9ec5636c776115af6d9664f 458df361e0761651b6d17f4fb730f996243bc9f3 2a5ea9ee0ba2b38d1810828a9fdf884d9b0fd198 e3b91687590f08438b5a5d4eec72e634b11a8589 57538e5f5002ecc2df95087244cb0431867c443e df90b9eaa16a52d076658ffc2fd1f65f12d1a622 2a1c5aba7640416c78501116dd42d12e74fe4734 66d3f24334e69e1655e83520950c59a0bda095a3 8a39b8ce354bd42325ff61c07cfdc7a150d2925a 91f7e9e02e72b46c881656a6b493fac276a6822b 33a417fc82ce3c5f1b3d435d912eb4b5afc52054 7a522da4f3946006fd325d498845225b8a8836f2 5f188d659e8601e577f3a837c9dd3459761371ac 92a78a052efcb3122932894fb446c62733daad42 9186ae043b7e8afa5730b9d70818360cdfef2201 359f33c5d0d39c4fcc57cba199a0d5b9a66c8fb9 b1391232450af9e81079a2afe2173c422c8e9e3b e639e3068c30bb614c394466f41fa450ee8b2dbb cf02151987b19b12ca0be463732765bd35f54028 2c92a92e2fa2503f0381b89f316f982eda580b6e 21a1bce4301d3d8de9702373c830d2e115223991 878f46727d8bcf1f75d056d9270ef3e2fe0b9d88 bb7d5ce2a8bd1dca51eb627aa2df811541053969 4347e3b15f10784b482544bd6324d3fcd4f0146c ec0080c40cfdb26896537f47a4c2e0439f9afdb1 commit 4c99a427ee4adaeddb2682c192384bad21d9d09b Author: Kohei Yoshida <kohei.yoshida@gmail.com> AuthorDate: Mon Jun 24 16:19:02 2013 -0400 Commit: Kohei Yoshida <kohei.yoshida@gmail.com> CommitDate: Mon Jun 24 16:51:45 2013 -0400 Fix incorrect merge. Change-Id: I1337413e1ee49b7d90671ac517dbb2bd918dbebf
(In reply to Timur from comment #3) > I don't understand what's the "crash" you experienced and is there any crash > report. x1sc0 replaced "crash" with "hang" in the report as we spoke on the IRC channel.
The same commit is also causing bug 108298, bug 108347 and bug 80853
Regression introduced in range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&c7bdee8dbd1cf260a8513a0d31b36f90daa70f1c..4c99a427ee4adaeddb2682c192384bad21d9d09b
*** Bug 112710 has been marked as a duplicate of this bug. ***
*** Bug 114245 has been marked as a duplicate of this bug. ***
*** Bug 116961 has been marked as a duplicate of this bug. ***
I have no crash and data is pasted to the hole column, about 83seconds Version: 6.1.0.0.alpha0+ Build ID: 6a3d2dea1da847f5bd6674b344162f087cceda8b CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; Locale: nl-BE (en_US.UTF-8); Calc: group
On my system, LO 5.3 takes 54 secs and LO 6.1+ takes just 14 secs. For filling 1 million rows. This was marked as regression, why? When it was faster? I see "in 4.1.0.0.alpha1+ it takes one second" but I don't repro that. I'm not sure this is a bug and I suggest this be closed as WFM.
Does not occur in current v6, but does in v5.41. However current behaviour is to replace entire column with DUPLICATES of the copied data from source until ~1 million columns. This is also bad behaviour. Suggest closure.
(In reply to mattreecebentley from comment #13) > Does not occur in current v6, but does in v5.41. Suggest closure. I was about to close and than it occured to me: why paste of cells A1 to A7 takes 14 secs and paste of cells A2 to A7 takes just 2 secs (on my system)? It's not about header, it's about cell content. If you replace "3" with "x" in A4 and paste cells A2 to A7 it's also longer. Why? > However current behaviour is to replace entire column with DUPLICATES of the > copied data from source until ~1 million columns. This is also bad behaviour. This is a behavior from OO. Can't say why it was made like that. I don't see use case for that behavior and paste takes time, user can think LO hangs. But that's another issue. That looks like a Bug 116961 but it said crash and there's no crash. So a new bug would be better.
(In reply to mattreecebentley from comment #13) > Does not occur in current v6, but does in v5.41. Suggest closure. I was about to close and than it occured to me: why paste of cells A1 to A7 takes 14 secs and paste of cells A2 to A7 takes just 2 secs (on my system)? It's not about header, it's about cell content. If you replace "3" with "x" in A4 and paste cells A2 to A7 it's also longer. Why? > However current behaviour is to replace entire column with DUPLICATES of the > copied data from source until ~1 million columns. This is also bad behaviour. This is a behavior from OO. Can't say why it was made like that. I don't see use case for that behavior and paste takes time, user can think LO hangs. But that's another issue.
It's not the case that the user may 'think' that it hangs, it genuinely does hang in 5.4.1. It does not hang in 6, but the behaviour is wrong.
I'll close this bug for original issue. But question remains: why paste of cells A1 to A7 takes 14 secs and paste of cells A2 to A7 takes just 2 secs (on my system)?
(In reply to Timur from comment #17) > I'll close this bug for original issue. > But question remains: > why paste of cells A1 to A7 takes 14 secs and paste of cells A2 to A7 takes > just 2 secs (on my system) I'm still slowness for the duplicates: bug 114245 & bug 112710. No actual crash Might be covered by bug 108298, bug 108347 or bug 80853
(In reply to Timur from comment #17) > why paste of cells A1 to A7 takes 14 secs and paste of cells A2 to A7 takes > just 2 secs (on my system)? Because A2:A7 has only numeric cell contents whereas A1 contains a text string. Effectively for pasting A2:A7 repeatedly to an entire column you end up with one segment of numeric cell data, for A1:A7 it is alternating 149796 text|numeric segments.