Description: With a stable, mature multi sheeet file I have updated to this version this afternoon and the moment I tried to group change some assorted fonts it hung, released, hung, released refused to respond, superheated my processor and when I allowed it to recover the document after a forced termination via Task Manager it recovered the original file prior to todays activity without any autosave activities. How do I know that? Because I was at Genius level on today's SBee and it recovered the opening file status which was genius level on yesterday's. It simply will not permit normal operations after the attempted font change. I reloaded all the parameters for today's issue and it again, allowed me to complete tasks but the moment I went to change the fonts it did the same thing. Changing the daily parameters and then enjoying the challenge to Genius level takes enough time for a couple of autosaves Steps to Reproduce: I have recovered and crashed this "stripped out" file three times to ensure this version is crashable for you. You may wish to try a few anagrams yourself to verify that it is functioning "normally" before you attempt to change the font in accordance with the instructions below. With the attached sheet select DI11:DI27. - This is just a "cache" of words that are missing from Marco Pinto's dictionary which I pass to him for inclusion - My English is more comprehensive than his dictionary ;) For the record, the first eleven cells are Liberation Sans and the remainder are Liberation Serif Type Libera in the BLANK font box and then open the pane to select Liberation Serif Having selected the new font, observe how the system seems to be confused. It can't quite decide whether it's not responding or what? It's certainly taking ages to make up its mind. You will also observe that there appears to be an interim rendition of an "unknown" font during the failure process. Try selecting any other cells and observe the delay. You might even want to try typing "Whinge" at CH17 - acceptable but "Hinge" at CH18 - is unacceptable as it's in the wrong location. Ensure it has been active long enough for more than one auto-save Try to exit with or without saving. Eventually you will be forced to terminate it through Task manager. open the document again and allow it to recover. Observe the failings I did not try to reset my profile because if it is a profile issue then the heading for this bug should be "LO corrupts the user profile when upgrading". I am going to uninstall and reinstall 7.4.5.1 because all my serious work would now be vulnerable. Actual Results: Corrupted files and crashed LO Expected Results: Continuity of the last 15 months of processing Reproducible: Always User Profile Reset: No Additional Info: Version: 7.4.6.2 (x64) / LibreOffice Community Build ID: 5b1f5509c2decdade7fda905e3e1429a67acd63d CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: sv-SE (en_GB); UI: en-GB Calc: threaded
Created attachment 186097 [details] Sample LO CALC
Update on the trigger mechanism: I rolled back LO and the issue persisted. I can run other LO files whilst the culprit is misbehaving and they process at normal speed. I recovered last night's file and it worked fine the first time I tried the block font change. I exited without saving and loaded again but this time it failed the moment I tried the block font change. Clearly, I must have done something different and have now established that it is the manner in which the block change is initiated that causes the issue. If the block is selected and there is a selection of fonts then the font name box is blank. If the font name is partially typed and the font dropdown is opened and the font is selected from those presented then it fails. However, If the block is selected and the font dropdown is directly opened and scrolled down to the font and the font is selected it works.
(In reply to Colin from comment #2) > Update on the trigger mechanism: As the cause has become more definitive I have changed the tagline to reflect the new reality. Feel free to ignore most of the initial report. I'll let one of you "big boys" decide whether the first comment should even be hidden as it's now mostly irrelevant. Sorry it was so verbose, I was trying to demonstrate that it must be a new bug associated with this release and it proved to be a minor variation in my actions exposing a pre-existing feature.
I selected AD6:AD7 and tried, but no problem on Windows or Linux. I did notice a small issue and created bug 154680 Arch Linux 64-bit, X11 Version: 7.5.2.2 (X86_64) / LibreOffice Community Build ID: 50(Build:2) CPU threads: 8; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US 7.5.2-1 Calc: CL threaded
(In reply to Buovjaga from comment #4) > I selected AD6:AD7 and tried, but no problem on Windows or Linux. > > I did notice a small issue and created bug 154680 > Arch Linux 64-bit, X11 > Version: 7.5.2.2 (X86_64) / LibreOffice Community > Build ID: 50(Build:2) > CPU threads: 8; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+xcb) > Locale: fi-FI (fi_FI.UTF-8); UI: en-US > 7.5.2-1 > Calc: CL threaded Perhaps the issue you have identified is an earlier stage of the extended operations I performed. Have you verified it using Windows 7.4.6.2 AND more importantly, allowed LO to perform a couple of autosaves BEFORE attempting to change the font? It may even be worthwhile creating a few anagrams yourself. It doesn't matter if you "copy" some existing solutions either into the correct columns or any of the other columns. If you replicate words in the correct columns and then sort ascending or descending with that column's autosfilter it will invoke more of the error checking. Just about anything to ensure LO has time to perform a couple of autosaves. As I advised - the malfunction occurred after it would have performed a couple of autosaves and before the attempted block font change.
(In reply to Colin from comment #5) > Have you verified it using Windows 7.4.6.2 AND more importantly, allowed LO > to perform a couple of autosaves BEFORE attempting to change the font? No.
(In reply to Buovjaga from comment #6) > (In reply to Colin from comment #5) > > Have you verified it using Windows 7.4.6.2 AND more importantly, allowed LO > > to perform a couple of autosaves BEFORE attempting to change the font? > > No. I just tried both this and your newer bug report. This still fails. What is apparent is that the font family on AD6:AD7 is Liberation sans - same font, same cut and it offers Liberation serif. However, the font on the selection I defined is the same family but both sans & serif cuts are used. It appears part of the trigger for the "freeze" and enforced closure is the fact that two different font cuts are selected and the expectation is that the selected font - however it is selected - will impose itself upon all the cells in the selection.
(In reply to Colin from comment #7) > (In reply to Buovjaga from comment #6) > > (In reply to Colin from comment #5) > > > Have you verified it using Windows 7.4.6.2 AND more importantly, allowed LO > > > to perform a couple of autosaves BEFORE attempting to change the font? > > > > No. > > I just tried both this and your newer bug report. > > This still fails. > > What is apparent is that the font family on AD6:AD7 is Liberation sans - > same font, same cut and it offers Liberation serif. However, the font on the > selection I defined is the same family but both sans & serif cuts are used. Ignore that, alternate cuts on AD6:AD7 as in the larger DI11:DI27 - my bad