Description: LibreOffice will crash at some point when clicking the the theme categories if no connection is made. Steps to Reproduce: 1.Open Writer 2. Tools -> Options -> LibreOfficeDev -> Personalization -> Select Theme 3. Disable the internet connection or block LibreOffice with a firewall 4. Click between all the categories. Ignore warnings (press OK) and keep clicking on different categories. Eventually it will crash. Actual Results: LibreOffice will crash Expected Results: LibreOffice shouldn't crash Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 5.4.0.0.alpha0+ Build ID: 88f561204d7cee25633df8117cc8d7e1ebd8e9ad CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-01-11_23:07:37 Locale: nl-NL (nl_NL); Calc: CL and in Versie: 5.3.0.1 Build ID: 3b800451b1d0c48045de03b5b3c7bbbac87f20d9 CPU Threads: 4; Versie besturingssysteem:Windows 6.2; UI Render: standaard; Layout Engine: new; Locale: nl-NL (nl_NL); Calc: CL User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Crash report: crashreport.libreoffice.org/stats/crash_details/76b7bf67-f7cc-4f79-8380-6ba5d20be418
I did retry it a few times. I get all sorts of crashes reports doing nearly the same. For example: 1. crashreport.libreoffice.org/stats/crash_details/040c7afa-316d-4d58-8ebb-eb7fb678308a (OutputDevice::ImplLayout(rtl::OUString const &,long,long,Point const &,long,long const *,SalLayoutFlags,vcl::TextLayoutCache const *) 2. crashreport.libreoffice.org/stats/crash_details/a975bb65-123e-471c-a06a-c16373967177 (vcl::Window::dispose()
Created attachment 130431 [details] bt with symbols On pc Debian x86-64 with master sources updated today + enable-dbgutil, I got a crash too but with a different bt.
Michael: considering the bug, does it correspond to the known scheduler pb or should I submit a specific bug? BTW, still now news about it? Anyway, let's put this one to NEW.
Reproduced in Version: 5.4.0.0.alpha1+ Build ID: 970b431f1a7b6b96c4c9536657ce4fe9d8f5b585 CPU threads: 1; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2017-05-11_23:07:53 Locale: es-ES (es_ES); Calc: group Steps: 1. Go to Tools -> Options -> LibreOfficeDev -> Personalization -> Select Theme 2. Select any category 3. Hold the Enter key eventually LibreOffice crashes Also reproduced in Versión: 4.4.0.3 Id. de compilación: de093506bcdc5fafd9023ee680b8c60e3e0645d7 Configuración regional: es_ES
Wow this is bad: #18 0x00002aaab466c8a7 in Button::SetModeImage (this=0x55555bfea100, rImage=...) at /home/julien/lo/libreoffice/vcl/source/control/button.cxx:178 #19 0x00002aaaf99fd828 in SelectPersonaDialog::ClearSearchResults (this=0x55555ba85680) at /home/julien/lo/libreoffice/cui/source/options/personalization.cxx:261 #20 0x00002aaaf9a00707 in SearchAndParseThread::execute (this=0x55555bf45410) at /home/julien/lo/libreoffice/cui/source/options/personalization.cxx:680 #21 0x00002aaaaf506ed8 in salhelper::Thread::run (this=0x55555bf45410) at /home/julien/lo/libreoffice/salhelper/source/thread.cxx:40 We should never call random VCL methods like Button::SetModeImage from a thread without first taking the Solar Mutex - that is what is caught here ... Quite probably we should add more of these checks to random Window:: methods to ensure that the correct thread is running =) I imagine this is the root of the crash.
Created attachment 133562 [details] protect VCL usage ... Sample patch, un-tested / compiled - might help etc. =) Of course, taking the SolarMutex rather defeats the purpose of threading this in the 1st instance ;-) Quite possibly we want to download the file in the thread and outside the SolarMutexGuard - and save it locally, before importing the image with a local file (might be worth a try) ...
See 0d860007d692f9fb15b5699b49c314eb72eae79b for an example on how to load a JPEG file safely on a thread. The bitmap creation is not thread-safe, so that has to be created on a main thread, the pixel-reading part can run on a thread. And also you need to make sure this is a JPEG file, other image filters don't have this separation between creating the bitmap and reading pixel data.
*** Bug 114156 has been marked as a duplicate of this bug. ***
Does this still happen? Asking as possible this is a duplicate of bug 113377 and/or bug 117866.
No repro Version: 6.2.0.0.alpha0+ Build ID: e7d3976cb80f7e7401be071f905a764dd6cb4d6e CPU threads: 4; OS: Windows 6.3; UI render: GL; TinderBox: Win-x86@42, Branch:master, Time: 2018-06-29_04:46:32 Locale: nl-NL (nl_NL); Calc: CL *** This bug has been marked as a duplicate of bug 113377 ***