This bug was filed from the crash reporting server and is br-1ee3063f-9ae7-478a-825e-fc935db342c1. ========================================= I simply changed two entries in an autosorted list and saved the document. It successfully saved the document as amended but "crashed" producing this report. Also, the recovery target report produced by the crash handling was empty. I did notice upon reloading the file that a conditional format colour scale was missing from one cell. Upon investigation, it was apparent that the single column had been broken into three individual ranges which were:- 1 cell 5-6 cells the entire range broken down into 4-5 sub ranges with overlaps but one cell was missing from the overlapping ranges. Remedy is simple - redefine one contiguous range and remove the surplus entries. For the record, any cutting and pasting or insertion/deletion of cells within a conditionally formatted array will always produce multiple overlapping entries in the editable conditional format management table. sometimes by concatenating new ranges to the defined range, sometimes creating additional overlapping entries. If there is no current awareness of this "feature" please advise and I will expedite the report.
Perhaps read alongside 141209 (closed by admin) - they may be duplicates but reopened by me as the events reoccurred yesterday and I now suspect "user profile" is a misdiagnosis.
(In reply to Colin from comment #1) > Perhaps read alongside 141209 (closed by admin) - they may be duplicates but > reopened by me as the events reoccurred yesterday and I now suspect "user > profile" is a misdiagnosis. Sorry 141229
Another crash with auto report caf8e1ef-8c65-4b1d-99b8-5247db8db819
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.)
Created attachment 173732 [details] Sample .ods The original has three sheets. It's a weight monitoring sheet so the only personal information is my daily weight movements. All the movements are on the DELETED sheet 1 and some magnified charts to compensate for failing eyesight are on the DELETED sheet 3. If the error fails to manifest itself I may need to give you the entire package which will also define that the error is associated with some other feature of the mechanism. (The other sheets lso have their own autofilters and conditional formatting). This sheet (originally 2) contains neither source nor destination data for either of the other sheets. The effect is only noticeable when inserting cells into the left portion of the spreadsheet and forcing cells DOWN. I may have sorted on either of the other filters prior to the insert however, that's not a procedural thing, just "as it happens". The only time it crashes is following the insert of a correctly sorted item into the "PRODUCT" grouping. You will also observe how this activity wreaks havoc with the Conditional formatting array for column E. If the formatting changes are monitored after every insert event it's not too "cluttered" but if the array is only examined after a few insert events it contains multiple abominations. Sometimes, when the extra "line" is inserted it doesn't contain any conditional data entries but generally, when conditional is required, one entry of the same value may be "cut & pasted" which invariably results in split and overlapping ranges all noted for column E.
My apologies if this appears to define two symptoms. The crash upon inserting a few cells and the corruption of the conditional formatting management array. It's not easy to define that they are unrelated - the array corruption is inherent in the insertion of new cells and the save crash is also inherent in the insertion. I have previously observed that the corruption may occur without the crash - or perhaps I just investigated and remedied corruption prior to saving and it is the remediation that obviated the crash.
Happened again, two images attached - apparently, the crash also locks the clipboard and I couldn't paste a screen grab so one of the attachments is a "camera grab". Also, Only one nominal change was made to the source sheet to induce the crash. I have tried to recreate the circumstances using the "cut-down" sheet submitted as an example but it failed to crash so I have now attached the full sheet For this failure I never inserted a range of cells into the left portion of the array I just modified a line that corrupted the Conditional format array, fixed the corruption and saved it. With sheet 2 of the attached file Verify >Format>condional>manage displays only one contiguous range E3:E89 D22 Enter 4 Select and copy E24 Paste to E22 Modify E22 to read 01/01/2022 Verify >Format>condional>manage displays an orphan E22 and an almost contiguous range E23:E89;E3:E21 Remove the orphan Edit the range to read E3:E89 Confirm & Exit I can't predict that it will crash first time for the tester but repeating the steps AND also the earlier steps to insert a few cells in the left table should have the (un)desired effect.
Created attachment 173802 [details] Screen dump
Created attachment 173803 [details] CameraDump
Created attachment 173804 [details] Full Function LOCalc sheet I have flagged the original sheet as obsolete as it's now possible to recreate it as desired from the new submission.
Same again today, simply inserted a line into an autosort array with conditional formatting - in the same file as has already been submitted. Attaching a screen dump of the crash notification screen and the file entry in the AppData Crash Folder. As per last time, the recovery list was empty. It seems odd to me that the crash report filed with LO has a different ID to the crash report file in the AppData crash folder. Is that symptomatic of something else also going pear shaped?
Created attachment 176871 [details] Screen Grab
Same again today - almost identical to #11 except I didn't insert the row I simply appended it to the end and then re-sorted. Crash report/recovery screen again failed to unload and LO was still running in the background with zero CPU. Killed it with Task Manager Again it produced multiple overlapping entries in the conditional format register which were manually amended to exclude the Singleton SAY E62 and the multi-range E3:E61;E63 The E: CF has two conditions ""=Default & <Today()-30 =Bad (Light Red 4 Highlight) As part of the routine, I would have amended some of the values in Column C and changed the date to today in Column E for those amendments. I used the TOOLBAR Today() Button The additional row was created by CTRL+C of B26:E26 with CTRL+V at B62 The array was then sorted ascending on B. This would have left a gap at A25 which was remediated by simply drag filling to the final row to resequence https://crashreport.libreoffice.org/stats/crash_details/75a26eb7-a196-4e84-9015-f8d4d0468387 Please advise whether I should ignore (NOT send) future crash reports on the same topic. I'm uncertain whether constantly filing the "same" report increases the urgency or simply pisses somebody off.🤷♂️
I'm sorry, I don't understand what should I do to reproduce the crash. Please provide step by step instructions. Thank you.
(In reply to raal from comment #14) > I'm sorry, I don't understand what should I do to reproduce the crash. > Please provide step by step instructions. Thank you. See comment 7 and ensure you have the latest attachment 173804 [details]
(In reply to Colin from comment #7) > > With sheet 2 of the attached file > > Verify >Format>condional>manage displays only one contiguous range E3:E89 > D22 Enter 4 > Select and copy E24 > Paste to E22 > Modify E22 to read 01/01/2022 > Verify >Format>condional>manage displays an orphan E22 and an almost > contiguous range E23:E89;E3:E21 > Remove the orphan > Edit the range to read E3:E89 > Confirm & Exit > > I can't predict that it will crash first time for the tester but repeating > the steps AND also the earlier steps to insert a few cells in the left table > should have the (un)desired effect. No repro with Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: a0bc0cc81b597aa81189355a8125753d6b873cce CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded
Colin please retest it in 7.4.2 version
(In reply to Roman Kuznetsov from comment #17) > Colin please retest it in 7.4.2 version Version: 7.4.2.3 (x64) / LibreOffice Community Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (en_SE); UI: en-US Calc: threaded I Couldn't get it to crash - no matter how hard I tried. Conditional Formatting creating orphan and non-contiguous ranges in the manager still exists. I'm not sure whether this is the anticipated behaviour or a "feature" worthy of a "feature" report - please advise.
Thanks for testing. About condition formatting, please see meta bug 87351. You can still open new bug about "creating orphan and non-contiguous ranges in the manager still exists".