Description: I send a crash report a5dfea8b-7410-4caa-bd07-ff30eb5df467 but would like to elaborate on it: The crash resulted in a complete lock-up of the computer, where not even Ctrl-Alt-Delete worked. I had to take the power cable of the computer and on the restart I suddenly was asked for a password to windows, which I usually don't use. When I restarted the computer again I wasn't asked about that again, but then my virusprogram WebRoot kept using 30 pct. of the CPU without it being because it was running a check. After another restart everything worked normally again. I was very surprised that an error in a resonably respected piece of software could have such a detrimental effect, and it makes me worry about the usability of Libre Office. Actual Results: I opened an Excel-file and looked at Styles, when everything froze. Expected Results: I didn't try to reproduce the problem. Reproducible: Didn't try User Profile Reset: No Additional Info: Kept working. Or at least just shut itself down without killing my computer.
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 201194 [details] Attached file #1
Created attachment 201195 [details] Attached file #2
Created attachment 201196 [details] Attached file #3
Enclosed is the file I was working on, when the computer froze. It was originally an Excel-file, which I saved as a Libre Office-file to see, what would happen to it if opened in Libre Office. I have also enclosed a screen print of Windows Reliability Monitor, so you can see what happened to Windows yesterday, when Libre Office crashed it. I've also enclosed a screen print of the message I got from Libre Office after the crash report was submitted.
Information is now supplied as good as I can.
According to the crashreport it seems rather related to Calc than Writer. I also noticed this line: sc/source/ui/theme/ThemeColorChanger.cxx:193 Do you remember anything related to changing color in theme?
You're right. I should have written Calc instead of Writer. I changed the color theme from one color scheme to another to see what effect it had on the colors already chosen in the file.
On pc Debian x86-64 with master sources updated today, I got an hang. To reproduce this, Menu Format/Theme. Remark: I also tested Menu Format/Spreadsheet theme but no freeze here even if it's a bit slow. Here's a random bt: #0 0x00007fabd536bee0 in std::get<0ul, ScColumn*, o3tl::default_delete<ScColumn> > (__t=std::tuple containing = {...}) at /usr/lib/gcc/x86_64-linux-gnu/14/../../../../include/c++/14/tuple:2452 #1 0x00007fabd536bec5 in std::__uniq_ptr_impl<ScColumn, o3tl::default_delete<ScColumn> >::_M_ptr (this=0x5571640a0fa0) at /usr/lib/gcc/x86_64-linux-gnu/14/../../../../include/c++/14/bits/unique_ptr.h:193 #2 0x00007fabd536bea5 in std::unique_ptr<ScColumn, o3tl::default_delete<ScColumn> >::get (this=0x5571640a0fa0) at /usr/lib/gcc/x86_64-linux-gnu/14/../../../../include/c++/14/bits/unique_ptr.h:465 #3 0x00007fabd54b326d in std::unique_ptr<ScColumn, o3tl::default_delete<ScColumn> >::operator* (this=0x5571640a0fa0) at /usr/lib/gcc/x86_64-linux-gnu/14/../../../../include/c++/14/bits/unique_ptr.h:448 #4 0x00007fabd54b2f05 in ScColContainer::operator[] (this=0x557160240480, nIndex=1450) at sc/inc/colcontainer.hxx:43 #5 0x00007fabd551c092 in ScTable::GetColumnData (this=0x557160240480, nCol=1450) at sc/inc/table.hxx:308 #6 0x00007fabd59d72f6 in Apply<(lambda at /home/julien/lo/libreoffice/sc/source/core/data/table2.cxx:3303:16)> (this=0x557160240480, rMark=..., nCol=1450, apply=...) at sc/inc/table.hxx:1500 #7 0x00007fabd59d0302 in ApplyWithAllocation<(lambda at /home/julien/lo/libreoffice/sc/source/core/data/table2.cxx:3303:16)> (this=0x557160240480, rMark=..., apply=...) at sc/inc/table.hxx:1492 #8 0x00007fabd59d00f0 in ScTable::ApplySelectionCache (this=0x557160240480, rCache=..., rMark=..., pDataArray=0x5572198047d0, pIsChanged=0x0) at /home/julien/lo/libreoffice/sc/source/core/data/table2.cxx:3302 #9 0x00007fabd55fde95 in ScDocument::ApplySelectionPattern (this=0x55715fdaa0b0, rAttr=..., rMark=..., pDataArray=0x5572198047d0, pIsChanged=0x0) at /home/julien/lo/libreoffice/sc/source/core/data/document.cxx:5956 #10 0x00007fabd66cf868 in sc::(anonymous namespace)::changeSheets (rDocShell=..., pViewShell=0x5571641e3230, pModel=0x55715fe15060, rColorSet=...) at /home/julien/lo/libreoffice/sc/source/ui/theme/ThemeColorChanger.cxx:201 #11 0x00007fabd66cee50 in sc::ThemeColorChanger::doApply (this=0x7ffffe39f448, pColorSet=std::shared_ptr<model::ColorSet> (use count 2, weak count 0) = {...}) at /home/julien/lo/libreoffice/sc/source/ui/theme/ThemeColorChanger.cxx:342
Created attachment 201213 [details] Flamegraph
Noel: thought you might be interested in the Flamegraph I attached. If not or no time, don't hesitate to uncc of course.
The problem here is that the changeSheets() function in ThemeColorChanger.cxx is creating monstrous amounts of undo data, because it creates a new undo sheet object for every single pattern attribute in the document. That code is going to need some serious improvement. It needs to use a custom undo object. A good starting point would be copying the existing ScUndoSelectionAttr class and modifying that to handle undo/redo of multiple patterns at once.