no need to delay-init something we always need, and laying
out a std::unordered_map is something we can normally do at
link time anyway.
Change-Id: Ide791d20394580bca615aa3ad564c154037e0816
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119137
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
In commit b33fbd55d6, many getMutex() have been replaced by an equivalent
maMutex.
Only in place, the use of a mutex have been simply removed.
Restore it as done in all the other places
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Change-Id: Id85e74e166ec57dd37f8913f8ecf19e2b6465f8f
---
This patch is completely speculative. The removal of this mutex was maybe
done on purpose.
This only looks spurious to me.
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117402
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This reverts commit 0752de6850, as it causes
initialization-order-fiasco, e.g. when building Gallery_backgrounds:
> ==913067==ERROR: AddressSanitizer: initialization-order-fiasco on address 0x7fee04a01ba0 at pc 0x7fee0467257e bp 0x7ffd678aaa30 sp 0x7ffd678aaa28
> READ of size 8 at 0x7fee04a01ba0 thread T0
> #0 in osl::Mutex::acquire() at include/osl/mutex.hxx:57:37 (instdir/program/libuno_cppu.so.3 +0x32957d)
> #1 in osl::Guard<osl::Mutex>::Guard(osl::Mutex&) at include/osl/mutex.hxx:138:17 (instdir/program/libuno_cppu.so.3 +0x316a4e)
> #2 in typelib_typedescriptionreference_new at cppu/source/typelib/typelib.cxx:2130:16 (instdir/program/libuno_cppu.so.3 +0x3e2d9a)
> #3 in typelib_static_type_getByTypeClass at cppu/source/typelib/static_types.cxx:266:17 (instdir/program/libuno_cppu.so.3 +0x3c04af)
> #4 in cppu::detail::getTypeFromTypeClass(_typelib_TypeClass) at include/cppu/unotype.hxx:110:9 (instdir/program/libxolo.so +0x2e87e61)
> #5 in cppu::detail::cppu_detail_getUnoType(signed char const*) at include/cppu/unotype.hxx:136:12 (instdir/program/libxolo.so +0x2e902dd)
> #6 in cppu::UnoType<signed char>::get() at include/cppu/unotype.hxx:296:16 (instdir/program/libxolo.so +0x2e90278)
> #7 in com::sun::star::uno::Type const& cppu::getTypeFavourUnsigned<signed char>(signed char const*) at include/cppu/unotype.hxx:321:12 (instdir/program/libxolo.so +0x2e90218)
> #8 in com::sun::star::uno::Type const& cppu::getTypeFavourUnsigned<signed char>(com::sun::star::uno::Sequence<signed char> const*) at include/com/sun/star/uno/Sequence.hxx:292:14 (instdir/program/libxolo.so +0x2e9001a)
> #9 in com::sun::star::uno::Sequence<signed char>::Sequence() at include/com/sun/star/uno/Sequence.hxx:59:26 (instdir/program/libxolo.so +0x2e8ff58)
> #10 in __cxx_global_var_init at xmloff/source/core/fasttokenhandler.cxx:35:48 (instdir/program/libxolo.so +0x3455d3f)
> #11 in _GLOBAL__sub_I_fasttokenhandler.cxx at xmloff/source/core/fasttokenhandler.cxx (instdir/program/libxolo.so +0x3455da4)
> #12 in call_init.part.0 at <null> (/lib64/ld-linux-x86-64.so.2 +0x108dd)
> #13 in _dl_init at <null> (/lib64/ld-linux-x86-64.so.2 +0x109c7)
> #14 at <null> (/lib64/ld-linux-x86-64.so.2 +0x10c9)
>
> 0x7fee04a01ba0 is located 0 bytes inside of global variable '(anonymous namespace)::s_Mutex' defined in 'cppu/source/typelib/typelib.cxx:286:12' (0x7fee04a01ba0) of size 8
> registered at:
> #0 in __asan_register_globals at ~/github.com/llvm/llvm-project/compiler-rt/lib/asan/asan_globals.cpp:360:3 (instdir/program/gengal.bin +0x28698d)
> #1 in asan.module_ctor at <null> (instdir/program/libuno_cppu.so.3 +0x42649b)
Change-Id: Iab673f048bfb76165de2c47c2db63e339069fd17
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110228
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...for LIBO_INTERNAL_ONLY. These had been missed by
1b43cceaea "Make many OUString functions take
std::u16string_view parameters" because they did not match the multi-overload
pattern that was addressed there, but they nevertheless benefit from being
changed just as well (witness e.g. the various resulting changes from copy() to
subView()).
This showed a conversion from OStringChar to std::string_view to be missing
(while the corresponding conversion form OUStringChar to std::u16string_view was
already present).
The improvement to loplugin:stringadd became necessary to fix
> [CPT] compilerplugins/clang/test/stringadd.cxx
> error: 'error' diagnostics expected but not seen:
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd]
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd]
> 2 errors generated.
Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
which means that some call sites have to change to use
unicode string literals i.e. u"foo" instead of "foo"
Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Add new methods "subView" to O(U)String to return substring views
of the underlying data.
Add a clang plugin to warn when replacing existing calls to copy()
would be better to use subView().
Change-Id: I03a5732431ce60808946f2ce2c923b22845689ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105420
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
current attempt isn't working, try a different approach to
silence these warnings
Change-Id: I0cc97df0897abc665dfbb683d7aa0df55f8affb2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103387
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
bDesctructorCalled doesn't exist in the code anymore.
I guess we can delete the comment.
Change-Id: I551efe2298422e5139f1dd07a6b3bf4728763026
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100774
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
While tracking down the issue discussed in the commit message of
78dc7d982b "Remove a potentially already enqueued
response when a bridge is disposed", it occurred to me that there should be a
race in those
uno_threadpool_putJob(
bridge_->getThreadPool(), ...);
calls in binaryurp/source/reader.cxx, when the bridge gets disposed (through
some other thread) between the time the bridge_->getThreadPool() call checks for
the bridge being disposed (in which case it would throw a DisposedException) and
the actual uno_threadpool_putJob call.
I tried to catch that with a previous incarnation of this change
(<https://gerrit.libreoffice.org/c/core/+/96120/1> "Jenkins Slides Through the
Tiny Window"), but couldn't---presumably because this race would be very rare
after all, and the issue I was chasing turned out to be caused by something
different anyway. Nevertheless, I wanted to address this potential race now.
We can only reliably check for disposed'ness after having locked ThreadPool's
m_mutex in uno_threadpool_putJob -> ThreadPool::addJob, but at which time we can
no longer indicate this condition to the caller---uno_threapool_putJob is part
of the stable URE interface, has a void return type, and should not throw any
exceptions as it is a C function. However, if the bridge gets disposed, any
threads that would wait for this job (in cppu_threadpool::JobQueue::enter,
either from cppu_threadpool::ORequestThread::run waiting to process new incoming
calls, or from a bridge's call to uno_threadpool_enter waiting for a respose to
an outgoing call) should already learn about the bridge being disposed by
falling out of cppu_threadpool::JobQueue::enter with a null return value. So it
should be OK if uno_threadpool_putJob silently discards the job in that case.
Change-Id: I36fe996436f55a93d84d66cc0b164e2e45a37e81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96120
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This avoids the need for the tricky osl::Condition::reset calls. For example,
the first one (in the "disposed !" case) had been added with
2a3ed89284 "sb132: #i112448# proper clean up in
JobQueue::enter (patch by olistraub)" as
> if( 0 == m_lstCallstack.front() )
> {
> // disposed !
> + if( m_lstJob.empty() )
> + {
> + osl_resetCondition( m_cndWait );
> + }
> break;
> }
>
and then change to
> if( 0 == m_lstCallstack.front() )
> {
> // disposed !
> - if( m_lstJob.empty() )
> + if( m_lstJob.empty()
> + && (m_lstCallstack.empty()
> + || m_lstCallstack.front() != 0) )
> {
> osl_resetCondition( m_cndWait );
> }
with cba3ac1eab "Avoid deadlocks when disposing
recursive JobQueue::enter", which prevented the reset from ever hapening
(because m_lstCallstack.front() cannot both be zero and non-zero here at the
same time). The std::condition_variable semantics nicely avoid any reasoning
whether or not a reset would be necessary here.
Change-Id: Ic9b57b836bb6679829f4aa3b68679256726acf60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96406
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...while a remote call is in progress. Otherwise, if the same thread later
makes another remote call (through another bridge), it would erroneously pair
the repsonse for the disposed call with the second call.
UITest_calc_demo started to fail that way occasionally, presumably after
77445e201c "Make Chart Creation Wizard async", but
for reasons rather unrelated to the contents of that commit. What apparently
happened is that in one test's tearDown, the bridge between the Python and the
soffice process happened to be disposed during the XDesktop::terminate call from
Python's main thread, so that the response (of type BOOLEAN) remained in the
JobQueue. Then during the next test's setUp, XUnoUrlResolver::resolve from
Python's main thread would internally make a remote queryInterface call for the
initial StarOffice.ComponentContext object, which returns an ANY of either VOID
or XInterface type. But that call was then mis-matched with the leftover
BOOLEAN response, causing failure.
I was able to reproduce that reliably on Linux with a local hack of
> diff --git a/cppu/source/threadpool/jobqueue.cxx b/cppu/source/threadpool/jobqueue.cxx
> index 6c9324521f40..a87770bf8935 100644
> --- a/cppu/source/threadpool/jobqueue.cxx
> +++ b/cppu/source/threadpool/jobqueue.cxx
> @@ -71,6 +71,7 @@ namespace cppu_threadpool {
> }
>
> m_cndWait.wait();
> + timespec ms{0, 1000000}; nanosleep(&ms, nullptr);
>
> struct Job job={nullptr,nullptr};
> {
introducing a sleep, so that other threads have a higher chance to dispose the
bridge (when the call being processed here is that XDesktop::dispose) after the
successful wait() but before the response is processed. UITest_calc_demo then
failed with
[...]
> Execution time for create_chart.CalcChartUIDemo.test_activate_chart: 6.520
> tearDown: calling terminate()...
> caught while TearDown:
> Traceback (most recent call last):
> File "uitest/libreoffice/connection.py", line 127, in tearDown
> xDesktop.terminate()
> libreoffice.connection.com.sun.star.lang.DisposedException: Binary URP bridge disposed during call binaryurp/source/bridge.cxx:611
>
> ok
> test_cancel_immediately (create_chart.CalcChartUIDemo) ...
[...]
> warn:sal.osl.pipe:423851:425076:sal/osl/unx/pipe.cxx:442: recv() failed: ECONNRESET
> warn:binaryurp:423851:425076:binaryurp/source/bridge.cxx:843: undisposed bridge "" in state 2, potential deadlock ahead
[...]
> ======================================================================
> ERROR: test_cancel_immediately (create_chart.CalcChartUIDemo)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "uitest/uitest/framework.py", line 25, in setUp
> self.connection.setUp()
> File "uitest/libreoffice/connection.py", line 176, in setUp
> conn.setUp()
> File "uitest/libreoffice/connection.py", line 57, in setUp
> self.xContext = self.connect(socket)
> File "uitest/libreoffice/connection.py", line 107, in connect
> xContext = xUnoResolver.resolve(url)
> uno.com.sun.star.uno.RuntimeException: initial object queryInterface for OID "StarOffice.ComponentContext" returned ANY of type boolean binaryurp/source/bridge.cxx:883
[...]
Change-Id: Icf9aadbb38e7aafffff844fe8e9ae99e165c1f33
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96326
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...in typelib_typedescription_register, in case they are already being
referenced from elsewhere. Instead, only move from *ppNewDescription to
pTDR->pType those members that were not yet initialized in the latter.
Change-Id: I7620219d137f8dd7f24a0f4a04eda30669b6c5a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93062
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...following up on 314f15bff0 "Extend
loplugin:external to warn about enums".
Cases where free functions were moved into an unnamed namespace along with a
class, to not break ADL, are in:
filter/source/svg/svgexport.cxx
sc/source/filter/excel/xelink.cxx
sc/source/filter/excel/xilink.cxx
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx
All other free functions mentioning moved classes appear to be harmless and not
give rise to (silent, even) ADL breakage. (One remaining TODO in
compilerplugins/clang/external.cxx is that derived classes are not covered by
computeAffectedTypes, even though they could also be affected by ADL-breakage---
but don't seem to be in any acutal case across the code base.)
For friend declarations using elaborate type specifiers, like
class C1 {};
class C2 { friend class C1; };
* If C2 (but not C1) is moved into an unnamed namespace, the friend declaration
must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see
C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither
qualified nor a template-id and the declaration is a function or an
elaborated-type-specifier, the lookup to determine whether the entity has been
previously declared shall not consider any scopes outside the innermost
enclosing namespace.")
* If C1 (but not C2) is moved into an unnamed namespace, the friend declaration
must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882>
"elaborated-type-specifier friend not looked up in unnamed namespace".
Apart from that, to keep changes simple and mostly mechanical (which should help
avoid regressions), out-of-line definitions of class members have been left in
the enclosing (named) namespace. But explicit specializations of class
templates had to be moved into the unnamed namespace to appease
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of
template from unnamed namespace using unqualified-id in enclosing namespace".
Also, accompanying declarations (of e.g. typedefs or static variables) that
could arguably be moved into the unnamed namespace too have been left alone.
And in some cases, mention of affected types in blacklists in other loplugins
needed to be adapted.
And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which
is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is
not moved into an unnamed namespace (because it is declared in
sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about
such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler
doesn’t give this warning for types defined in the main .C file, as those are
unlikely to have multiple definitions."
(<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The
warned-about classes also don't have multiple definitions in the given test, so
disable the warning when including the .cxx.
Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4
Reviewed-on: https://gerrit.libreoffice.org/83239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...where the latter are reportedly expensive. Both
<https://gerrit.libreoffice.org/#/c/75162/> "tdf#121740 related, cache external
mapping in cppu::loadExternal" and <https://gerrit.libreoffice.org/#/c/82261/>
"tdf#121740 add cache to win osl_getModuleURLFromAddress" attempted to reduce
the costs observed when loading one specific document by introducing caches
below cppu::detail::loadModule's call to osl::Module::loadRelative.
On the other hand, this change reduces the number of calls to
osl_getModuleURLFromAddress by computing the base URI in
cppu::detail::loadModule only once. For my local Linux --enable-dbgutil build,
for `instdir/program/soffice '109340 class14.ppt'` and then exiting LO again
(with the document attached at
<https://bugs.documentfoundation.org/show_bug.cgi?id=121740#c0>), this reduces
the number of calls to osl_getModuleURLFromAddress from 3775 to 22.
(Many of those calls originated from cppu::getCaughtException or
cppu::throwException, as in
osl_getModuleURLFromAddress
osl_getModuleURLFromFunctionAddress
osl::Module::getUrlFromAddress
osl_loadModuleRelative
osl::Module::loadRelative
cppu::detail::loadModule
cppu::loadModule
cppu::loadExternalMapping
uno_getMapping
com::sun::star::uno::Mapping::Mapping
cppu::throwException
.)
Unfortunately, this needs to duplicate functionality from osl_loadModuleRelative
(sal/osl/all/loadmodulerelative.cxx) somewhat, as the stable SAL interface only
offers functionality to load relative to a given function, not relative to a
given base URI. (And extending the stable SAL interface for this one use is not
worth the maintenance costs.)
Change-Id: Ib58814136d11c67d1419b0224d12e30bb710e613
Reviewed-on: https://gerrit.libreoffice.org/82290
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
if one side of the expression is a compile-time-constant, we don't need
to worry about side-effects on the other side
Change-Id: Iee71ea51b327ef244bf39f128f921ac325d74e2b
Reviewed-on: https://gerrit.libreoffice.org/81589
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...that had been missing because the plugin didn't implement postRun, so it
didn't report anything when run as part of the shared plugin. (But did report
the expected warnings when run as a standalone plugin during
CompilerTest_compilerplugins_clang.)
Most fixes are straightforward. A noteworthy one is PreparedStatement::setBytes
in connectivity/source/drivers/postgresql/pq_preparedstatement.cxx: The old
preallocation of a 20 character OStringBuffer might have prevented
buf.append( reinterpret_cast<char *>(escapedString), len -1 );
from potentially throwing std::bad_alloc, which would have caused escapedString
to be leaked. Even though that 20-character preallocation was likely just
random junk and not meant to address the potential leak, lets address it now.
Change-Id: Ib506332d061684a22a74e5e39e591539fd2c4900
Reviewed-on: https://gerrit.libreoffice.org/80925
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
look for OUStringBuffer append sequences that can be turned
into creating an OUString with + operations
Change-Id: Ica840dc096000307b4a105fb4d9ec7588a15ade6
Reviewed-on: https://gerrit.libreoffice.org/80809
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Noel Grandin