Created attachment 53617 [details] zipped folder with two files inside Selecting an entire column (by clicking into its letter in the column heading of a spreadsheet, e.g. column F), then pasting something into that column causes a hang. Steps to reproduce: -- Select a column that has data in it, by clicking on the column header (so the entire column is selected) In my case it was column F. -- from somewhere else, copy some data - in my case, I copied six rows and two columns worth of cells, just text and numbers in those cells. -- paste it (standard paste, not special) into the original document - in my case, I had about 1900 rows of data (by about 30 columns) that started in row 8 (rows 1-7 were blank), and I was attempting to paste that 6x2 data into F1,(again column F was already selected - but the attempted paste wouldn't or shouldn't have actually overwritten anything already there.) ==>> The warning dialog about cells already having data, are you sure you want to overwrite -- I take the default to overwrite the data RESULTS: hang, spinning beachball cursor, eventually the applications is "Not Responding" and you have to force quit - and lose all your data that is not yet saved My Configuration: MacBook Pro late 2006, Mac OS 10.5.8 (not sure about which Intel processor it is in the Hardware pop-up of this bug report, so I chose "Other") I've seen this before in Open Office, never in Excel, I don't believe. It's like Calc has no conception of where the lowest row of data is, and dumbly just goes on forever down to row infinity, ATTACHMENTS (two BBEdit files in a zip-compressed folder called "Column selected paste hang bug"): 1) A sample graph from the Mac OS X Terminal app while the beachball was spinning, and 2) the bug report info sent to Apple that comes up when you force quit (both the "Problem Details" and "System Configuration" sections are included.)
It does not crash here with 3.4.4 on Linux. It filled the column until the row 1048576. Well, I might have been just lucky. Another question is if this operation makes sense. IMHO, LO should warn before doing such thing. It is a corner case. The operation does not make much sense. Of course, LO should not crash but such bug can't block the release => lovering the priority a bit
This is a feature and not a bug. If you select a range larger than the copied range calc pastes as many times as possible the content into this range. We might need to rethink this feature in future but right now this is not a bug.
Good Luck with your LibreOffice where selecting a column becomes an adventure. I've purchased Office for Mac 2011
I vote to reopen this "Feature" report. I created a trivial formula in a cell (=A1+B1), copied it, selected the whole column and pasted it. LO hangs 1 core 100% -> after 5min Mem fills up (8Gb) -> System hangs The mem fillup rate is not linear, it "lingers" a while at 1 to 1.5 Gb and then goes to 80% in 2 minutes or so. This is problematic. I understand the argument for this "do this to a potentially infinite column of this sheet". In these Programs however, pasting something into a column largely means: "Please column, behave this way!". Otherwise I'd recommend to disable pasting into columns, because it is almost never what you want it to do. Even Gnumeric is smart enough to catch this by asking "Do you really want to paste 65535 copies?(y/n)"! And even when I say yes it doesn't die as LO does. As I understand it their infinity is only about 6% of your infinity but, well, at least I can paste into a column without an adrenaline rush. I dare not fiddle with the controls as this is my first bug report here, but please oh please rethink this one. Sysinfo: uname -srvpio Linux 3.2.0-3-amd64 #1 SMP Mon Jul 23 02:45:17 UTC 2012 unknown unknown GNU/Linux (Debian Testing) Package: libreoffice-calc Source: libreoffice Version: 1:3.5.4+dfsg-2 Installed-Size: 23894 Maintainer: Debian LibreOffice Maintainers <debian-openoffice@lists.debian.org> Architecture: amd64
*** Bug 61365 has been marked as a duplicate of this bug. ***
Lost my work by crashing LibreOffice calc. Closing in Gnome does not work, soffice keeps running. Had to kill soffice in the terminal. Steps to reproduce: - type something in A1 - type soemthing in A2 - select A1..A2 - copy - click on column B by accident instead of selecting B1 - paste: memory usage rises, program hangs, work lost. Talked to colleagues about this, they also experienced this too many times. They are now using Microsoft Excel, because of this (and also because of the too low maximum amount of columns possible). Mission critical. Fix it or disable it!
This is a serious bug that is reproducible in Openoffice, Libreoffice, and Neoffice, on my Macbook Pro, 10.8.5. Basically makes the spreadsheet application of these MS Office alternatives useless. (In reply to comment #6) > Lost my work by crashing LibreOffice calc. > Closing in Gnome does not work, soffice keeps running. > Had to kill soffice in the terminal. > > Steps to reproduce: > > - type something in A1 > - type soemthing in A2 > - select A1..A2 > - copy > - click on column B by accident instead of selecting B1 > - paste: memory usage rises, program hangs, work lost. > > Talked to colleagues about this, they also experienced this too many times. > They are now using Microsoft Excel, because of this (and also because of the > too low maximum amount of columns possible). > > Mission critical. > Fix it or disable it!
This bug applies equally to rows. It is very likely that a user will mistakenly select an entire row or column when intending to select the first cell in that row or column, thus triggering this bug and potentially losing a lot of work.
Just wanted to add that this issue still appears in Version: 4.2.4.2. If a user selects an entire row or column eventually LO will hang and crash as it continues selecting cells into infinity. It is hard to see how this is a feature. We are testing this suite to see if it might be a fit for our company and this is the first real deal breaker we have encountered. Is there any insight into a fix or workaround for this issue?
This was closed by one of our most experienced spreadsheet developers (Markus). Please don't reopen it as it currently is. If you are so inclined, please create a new feature request that details what you expect to happen. As I see it, this is a feature, not a bug. Again please don't reopen this bug, as it is written now with the description, it's a feature, not a bug. See comment 2. So the question that must be answered on any new feature request is "what do you expect to happen when you copy and then paste into a much larger set of cells." Would a dialog warning that if you continue it may freeze depending on how many cells were selected/pasted in suffice? Would an autosave immediately before a large paste be better? Please be clear, objective, and without blame in your new report. Thanks
*** Bug 68156 has been marked as a duplicate of this bug. ***