I believe this might be related to https://crashreport.libreoffice.org/stats/signature/dbaccess::ODatabaseDocument::impl_attachResource Steps to reproduce: 1. Open any database file 2. Kill LibreOffice's process 3. Launch LibreOffice - Recover dialog is prompted with the database file listed 4. Click on 'Start' -> Crash Reproduced in Versió: 6.3.3.2 ID de la construcció: 1:6.3.3-0ubuntu0.18.04.1~lo1 Fils de CPU: 4; SO: Linux 4.15; Renderitzador de la IU: per defecte; VCL: gtk3; Configuració local: ca-ES (ca_ES.UTF-8); Llengua de la IU: ca-ES Calc: threaded
Why do you put this as major since killing LO isn't a current use case?
Created attachment 156332 [details] gdb backtrace
looking at the backtrace attached, definitely related to https://crashreport.libreoffice.org/stats/signature/dbaccess::ODatabaseDocument::impl_attachResource
Also reproduced in Version: 6.5.0.0.alpha0+ Build ID: b6c357506740d14611603a4611f4aacaffe4ee13 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: x11; TinderBox: Linux-rpm_deb-x86_64@86-TDF-dbg, Branch:master, Time: 2019-11-30_08:59:17 Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded I believe this is a regression but I can't bisect it with the bisect repositories since the recover dialog is not displayed after killing LibreOffice
I can't help here => uncc myself.
Hi Caolán, Might the crash be related to the welding of RecoveryDialog < https://cgit.freedesktop.org/libreoffice/core/commit/?id=a9eb7df678655bd71f062ba404b7d6b6f9cc18d4 > ??
I can reproduce the assert but I don't think its weld-related dbaccess/source/core/dataaccess/databasedocument.cxx:686 has an explicit aGuard.clear(); // (load has an own guarding scheme) and then goes and passes that in to impl_attachResource which calls _rDocGuard.clear(); on it. Since commit d38f9934f08939032cca64a32de58fa3901a88d5 Date: Sun Apr 7 15:29:35 2019 +0100 [API CHANGE] Asserts to never clear already cleared guard this asserts. Not sure what the right fix is, but https://gerrit.libreoffice.org/#/c/84778/ seems to work, maybe Mike has an idea if that fix makes sense
(In reply to Caolán McNamara from comment #7) > I can reproduce the assert but I don't think its weld-related > > dbaccess/source/core/dataaccess/databasedocument.cxx:686 has an explicit > > aGuard.clear(); // (load has an own guarding scheme) > > and then goes and passes that in to impl_attachResource > > which calls > > _rDocGuard.clear(); > > on it. > > Since > > commit d38f9934f08939032cca64a32de58fa3901a88d5 > Date: Sun Apr 7 15:29:35 2019 +0100 > > [API CHANGE] Asserts to never clear already cleared guard > > this asserts. > > Not sure what the right fix is, but > https://gerrit.libreoffice.org/#/c/84778/ seems to work, maybe Mike has an > idea if that fix makes sense Finally I learnt how to bisect this kind of issues <https://wiki.documentfoundation.org/QA/Bibisect#How_to_bisect_File_Recovery_bugs> and indeed it points to https://cgit.freedesktop.org/libreoffice/core/commit/?id=d38f9934f08939032cca64a32de58fa3901a88d5
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/23c024e7267510c09d89be934e526d56f76ec11b tdf#129210 don't assert with clear on already cleared mutex It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/commit/79fdc6e0a3a44642ac8d49225f14241872097fb7 tdf#129210 don't assert with clear on already cleared mutex It will be available in 6.3.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/a678785337d5caff9354d9d3500bcd098888d7a5 tdf#129210 don't assert with clear on already cleared mutex It will be available in 6.4.0.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified in Version: 6.5.0.0.alpha0+ Build ID: f86824cca0c442d371379d2ea0bff2241f18ab3d CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @Caolán, thanks for fixing this issue!!