Description: See also: https://crashreport.libreoffice.org/stats/crash_details/375b6a4a-1c64-40df-9f11-3e2228f9f84e This happened when opening an existing .ODT document by double-clicking it in windows explorer while another .ODT and .ODS document were already open. A similar situation seems to have happened minutes before as a result of the same action (but opening another .ODT document). Steps to Reproduce: Not reliably reproducable. I do this all the time and only twice did it go wrong. Actual Results: Crashed with reference stack trace. Expected Results: File is opened, no crash. Reproducible: Couldn't Reproduce User Profile Reset: No Additional Info: See referenced crash report.
I can't confirm this with Version: 7.0.0.0.alpha1+ (x64) Build ID: 99c337d1d3831ce9d2c7dc1cbff713f4ac49d6ac CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win; Locale: de-DE (de_DE); UI: en-GB Calc: CL I think some more informations are needed to reproduce it.
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.)
I would love to be able to provide a sample document, because that means I can reproduce the issue. I've tried, with the same documents as well as with others, and I still work the way I described on a near-daily basis. I have not seen this beyond the two instances in the original report. The stack trace indicates this was caused by a mutex release. The first thoughts then (to me, as a software engineer) are a double release or an unacquired release. The latter is probably not the case (those tend to be noticeable) so it seems most likely that we're looking at a rare race condition that can lead to a double release. I am very much aware of how hard finding those can be. I see two possible ways forward. One is detecting the double release and somehow dealing with it or getting information from that. That would be a workaround for the crash and still indicates another problem since apparently some mutex-protected code just ran without that protection - and you still won't know where the initial release came from without very expensive self-debugging mutexes with explicit active-lock lists. The other is going through all uses of this mutex and making sure they are correctly acquired and released in all possible circumstances, which can be incredibly tedious depending on how widespread this mutex is. Beyond these thoughts I can be of no help, I'm afraid. I will change the status back to UNCONFIRMED despite not providing a document. It's up to the team where to take it from there.
Ok, thanks for the input. Let's do one thing: Letts close it as RESOLVED WORKSFORME for now and if your reproduce it again, please put this issue back to UNCONFIRMED. Thanks
Hm, there are many crashs with that signature: https://crashreport.libreoffice.org/stats/signature/typelib_typedescriptionreference_release A crash with that signature happened with 6.4.7.2 when opening the print preview ... but I'm not able to reproduce that consciously.