This bug was filed from the crash reporting server and is br-1c4a5d1c-a000-42c7-bbc5-8d2de6b21ce9. ========================================= All I did was double click a desktop link to a perfectly functioning sheet. I had previously deactivated Advanced features and Large sheets. I also thought I had successfully opened files following that re-setting Version: 7.2.5.2 (x64) / LibreOffice Community Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5 CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: sv-SE (en_GB); UI: en-GB Calc: threaded Jumbo
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
*** Bug 146813 has been marked as a duplicate of this bug. ***
Deleting & Rebuilding user profile appears to be the remedy however, the user profile WAS corrupted by enabling experimental features and large spreadsheet.
Probably safe to mark this as SOLVED as it was a system generated duplicate. My apologies, still having trouble with identifying the appropriate procedures as the only way to get a report ID to try to ascertain whether it already exists is to file it and then discover it's a duplicate
Although crash is evident, confirming bug requires reproducible steps. From what you wrote, we may close the report, but let it stay as Needinfo for a few months, to see if you will be able to find steps.
(In reply to Timur from comment #6) > but let it stay as Needinfo > for a few months, to see if you will be able to find steps. I only activated the experimental features so I could experiment with a large spreadsheet where transposing 3000+ columns would not exceed the 1024 column limit of the standard layout. I could provide you with the spreadsheet I was working with together with the instructions gleaned from an ASKLibre topic. I got as far as selecting a matrix with CTRL+* and copying the 26x3954 matrix of 5 character words with CTRL+C and simply tried to paste special with transpose into the area adjacent to the lower right point of the original matrix. It crashed the moment I Ok'd it. I did try a few times and it was remarkably consistent😒 the biggest issue for me was that it continued to crash everything I loaded until I trashed the profile. The columns were of various row counts so the dimensions given are overall - only 12923 of the 102804 total cells were populated. I had too much faith in the product's stability and paid the price. The same attempt on the standard sheet simply advised me that I was trying to squeeze 3k+ columns into a 1024 column space - give it up! One promise I can make is that I won't be doing that again in a hurry. Please advise if you require the sheet - no personal info so no worries.
[Automated Action] NeedInfo-To-Unconfirmed
If you can reproduce the bug with the sheet and "Large sheets" on, please attach ODS. If not, it's not reproducible, bug can only be closed.
(In reply to Timur from comment #9) > If you can reproduce the bug with the sheet and "Large sheets" on, please > attach ODS. Attached herewith, it's not a case of reproducing the bug - it never does anything but crash when attempted - and effectively destroys the ability to load and save any random LO file without the Erroneous Crash/Recovery Handling which is only remediated by trashing and rebuilding my user profile. In the spreadsheet @ C1 is a URL Button to the ASKLO topic for turning an array into a single column. As my array is not a uniform rectangle commencing at A1 then it's necessary to select the cells for transposition from the address box - the target range being I8:AH3956. This caters for the fact that my array cell population is not rectangular, the columnar row counts being the green numbers on row 5 Both versions of the prescribed #2 action - CTRL+C & CTRL+Ins successfully copy the data to the clipboard Instruction #3 of JOHNSUN'S solution is replaced with a targeted jump in the address field to AK3956 to achieve the same focus relativity as the example. The next instruction #4 CTRL+SHFT+V T [Enter] is always the "crash point" for me.
Created attachment 177631 [details] Source document with substantial arrray
Perhaps I should clarify; After a few attempts to follow the procedure with each attempt crashing, I then removed the Experimental Features and Large Spreadsheet capabilities. I'm not 100% certain whether the crash/recovery handling of any new file opening or saving was evident before I reset the parameters but it is certainly evident with any endeavour to process a CALC file after the parameters have been reset and CALC restarted. The damage even transcends a full PC shutdown and restart. Are we talking about Two bugs here? 1 - The crash on trying to transpose the data 2 - The constant crash/recovery procedure with any subsequent file open, modify, save sequence
Steps (with Experimental feature Enable very large spreadsheets): 1. open ODS attachment 177631 [details] 2. Ctrl+* (or Edit-Select-Select Data Area) 3. Ctrl+C (or Ctrl+Ins - copy data to clipboard) 4. Ctrl+End and twice Right arrow (to move cursor to empty cell) 5. Ctrl+Shift+V (menu Edit-Paste Special), T (choose Transpose) Repro 7.0 with Fatal Error box and crash. Repro 7.2 and 7.4+ with crash. Doesn't seem like a regression but problem with Jumbo sheets. Paste transposed in step 4. works to a new sheet but not to the same one. Note: in 7.4+ I once got a message: Protected cell cannot be modified. But I guess I marked something wrong.
(In reply to Timur from comment #13) > Steps (with Experimental feature Enable very large spreadsheets): > > Note: in 7.4+ I once got a message: Protected cell cannot be modified. But I > guess I marked something wrong. I got that as well So we must have both randomly produced the same error ;)
(In reply to Colin from comment #14) > (In reply to Timur from comment #13) > > Steps (with Experimental feature Enable very large spreadsheets): > > > > > Note: in 7.4+ I once got a message: Protected cell cannot be modified. But I > > guess I marked something wrong. > > I got that as well So we must have both randomly produced the same error ;) Also, have you experienced the issue with subsequently opening any CALC file and constantly encountering the crash/recovery procedure?
(In reply to Colin from comment #15) > Also, have you experienced the issue with subsequently opening any CALC file > and constantly encountering the crash/recovery procedure? Please let's focus on a single defined issue. Maybe you still have LO running or not starting after the crash, just kill it in Task Manager. Note: I don't see it like that, but Jumbo sheets are experimental, so bugs are marked with Normal priority. Which is less important from the fact that it still needs a volunteer or paid dev: No further comments please.
(In reply to Timur from comment #16) > (In reply to Colin from comment #15) > No further comments please. Understood, Verbose user disabled ;)
Hi Roland. I was free to add you here due to your work on Paste Transposed and seeing that you are active. Here it's again Paste Transposed, this time crash if Jumbo sheets is used. No crash if paste is normal or to other sheet. Feel free to remove yourself or disable mails if not interested.
Works with current master, fixed by https://cgit.freedesktop.org/libreoffice/core/commit/?id=8bb457d17ef970676f60976cc4e2de9c9f5340c0 .