I'd like to cherry-pick the attached to 3.3
It should fix https://bugzilla.redhat.com/show_bug.cgi?id=661809
This is a long story, but see the backtrace attachment at the above url
there thread 1 and thread 8 both end up mangling libgcrypt which neon is
using.
https://bugzilla.redhat.com/show_bug.cgi?id=637738 is an earlier one
which is already fixed in 3.3
What happens is that normally neon thread-safely inits libgcrypt and in
most other threaded apps it all works fine. In OOo however we happens to
init cups before we init neon, so cups inits libgcrypt
*non-thread-safely*, and once initted libgcrypt cannot be re-initted to
be thread safe again.
Aha, you say, why not just fix cups to initialize gcrypt thread-safely,
well, been there, done that.
https://bugzilla.redhat.com/show_bug.cgi?id=544619
Alas if you do, then someone dlopens cups, dlcloses it and libgcrypt
provides no way to be *de*initted correctly, i.e. then this happens.
https://bugzilla.redhat.com/show_bug.cgi?id=559940
https://bugzilla.redhat.com/show_bug.cgi?id=553834
where the locking methods that libgcrypt now relies upon have been
ripped away by the dlclose of cups.
C.
From 177e8bb078617aeb799cf28b20157f245baa0c78 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Caol=C3=A1n=20McNamara?= <caolanm@redhat.com>
Date: Thu, 9 Dec 2010 20:32:23 +0000
Subject: [PATCH] Resolves: rhbz#668109 ne_simple_propfind can touch gcrypt as well
---
ucb/source/ucp/webdav/NeonPropFindRequest.cxx | 18 ++++++++++++------
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/ucb/source/ucp/webdav/NeonPropFindRequest.cxx
b/ucb/source/ucp/webdav/NeonPropFindRequest.cxx
index a1ddfb2..17d42cc 100644
--- a/ucb/source/ucp/webdav/NeonPropFindRequest.cxx
+++ b/ucb/source/ucp/webdav/NeonPropFindRequest.cxx
@@ -260,6 +260,8 @@ extern "C" void NPFR_propnames_results( void* userdata,
theResources->push_back( theResource );
}
+extern osl::Mutex aGlobalNeonMutex;
+
// -------------------------------------------------------------------
// Constructor
// -------------------------------------------------------------------
@@ -287,12 +289,15 @@ NeonPropFindRequest::NeonPropFindRequest( HttpSession* inSession,
thePropNames[ theIndex ].nspace = NULL;
thePropNames[ theIndex ].name = NULL;
- nError = ne_simple_propfind( inSession,
- inPath,
- inDepth,
- thePropNames,
- NPFR_propfind_results,
- &ioResources );
+ {
+ osl::Guard< osl::Mutex > theGlobalGuard( aGlobalNeonMutex );
+ nError = ne_simple_propfind( inSession,
+ inPath,
+ inDepth,
+ thePropNames,
+ NPFR_propfind_results,
+ &ioResources );
+ }
for ( theIndex = 0; theIndex < thePropCount; theIndex ++ )
free( (void *)thePropNames[ theIndex ].name );
@@ -302,6 +307,7 @@ NeonPropFindRequest::NeonPropFindRequest( HttpSession* inSession,
else
{
// ALLPROP
+ osl::Guard< osl::Mutex > theGlobalGuard( aGlobalNeonMutex );
nError = ne_simple_propfind( inSession,
inPath,
inDepth,
--
1.7.3.2
Context
- [Libreoffice] Code review for some threadlocking in webdav · Caolán McNamara
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.