[Libreoffice-commits] core.git: tsan-suppress.txt

Noel Grandin (via logerrit) logerrit at kemper.freedesktop.org
Fri Jul 30 15:54:37 UTC 2021


 tsan-suppress.txt |   37 +++++++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

New commits:
commit f1600c169bd2114505344a100cdc383539f76dbc
Author:     Noel Grandin <noel.grandin at collabora.co.uk>
AuthorDate: Fri Jul 30 15:22:30 2021 +0200
Commit:     Noel Grandin <noel.grandin at collabora.co.uk>
CommitDate: Fri Jul 30 17:54:00 2021 +0200

    TSAN suppression file
    
    Change-Id: I07a56a4dd7543ca3faf265110bcf02aaafec1b2e
    Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119708
    Tested-by: Jenkins
    Reviewed-by: Noel Grandin <noel.grandin at collabora.co.uk>

diff --git a/tsan-suppress.txt b/tsan-suppress.txt
new file mode 100644
index 000000000000..d6130b285df8
--- /dev/null
+++ b/tsan-suppress.txt
@@ -0,0 +1,37 @@
+#
+# This file is part of the LibreOffice project.
+#
+# This Source Code Form is subject to the terms of the Mozilla Public
+# License, v. 2.0. If a copy of the MPL was not distributed with this
+# file, You can obtain one at http://mozilla.org/MPL/2.0/.
+#
+
+# Use via environment variable TSAN_OPTIONS=suppressions=.../tsan-suppress.txt
+
+# There looks to be a lock ordering problem here, but I can't see how it could
+# actually be hit in practice.
+deadlock:cppuhelper::ServiceManager::disposing()
+deadlock:cppuhelper::ServiceManager::loadImplementation
+
+# Ignore stuff in external DBUS library
+# Some kind of dbus lock issue when we call it from psp::CUPSManager
+deadlock:_dbus_lock
+
+# inside an assert so I don't care
+race:cppu::OWeakConnectionPoint::acquire
+race:AffineBridge::v_enter
+race:__vsnprintf_chk
+
+# right now, I'm not interested in deadlocks at all, too many false+
+deadlock:
+
+# This is checking  SAL_STRING_IS_STATIC, which is safe because that is written at compile time
+race:rtl::str::acquire<_rtl_uString>
+race:rtl::str::release<_rtl_uString>
+
+# I've convinced myself this is a false+, caused by ping-ponging the buffer between two
+# threads, but I might be wrong
+race:XBufferedThreadedStream::getNextBlock
+
+# not introduced in stuff the embedded JVM does
+race:libjvm.so


More information about the Libreoffice-commits mailing list