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>
...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>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ia1b2f0a9c99acc7ac538f3b41c1b6757d414db35
Reviewed-on: https://gerrit.libreoffice.org/66970
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
...where "inline" (in its meaning of "this function can be defined in multiple
translation units") thus doesn't make much sense. (As discussed in
compilerplugins/clang/redundantinline.cxx, exempt such "static inline" functions
in include files for now.)
All the rewriting has been done automatically by the plugin, except for one
instance in sw/source/ui/frmdlg/column.cxx that used to involve an #if), plus
some subsequent solenv/clang-format/reformat-formatted-files.
Change-Id: Ib8b996b651aeafc03bbdc8890faa05ed50517224
Reviewed-on: https://gerrit.libreoffice.org/61573
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...warning about (for now only) functions and variables with external linkage
that likely don't need it.
The problems with moving entities into unnamed namespacs and breaking ADL
(as alluded to in comments in compilerplugins/clang/external.cxx) are
illustrated by the fact that while
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
returns 1, both moving just the struct S2 into an nunnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
namespace { struct S2: S1 { int f() { return 1; } }; }
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
as well as moving just the function f overload into an unnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
namespace { int f(S2 s) { return s.f(); } }
}
int main() { return f(N::S2()); }
would each change the program to return 0 instead.
Change-Id: I4d09f7ac5e8f9bcd6e6bde4712608444b642265c
Reviewed-on: https://gerrit.libreoffice.org/60539
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...from function definitions occurring within class definitions. Done with
a rewriting Clang plugin (to be pushed later).
Change-Id: I9c6f2818a57ccdb361548895a7743107cbacdff8
Reviewed-on: https://gerrit.libreoffice.org/34874
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...implying that pLocalThreadId, nRefCountOfCurrentId, pCurrentId are
initialized, implying that zero-initializing them during construction isn't
necessary.
Change-Id: I98399203694edde14abc664a82861ba50dfb357c
Depending on timing, it can apparently happen at least during
JunitTest_unordf_complex that a cppu_threadpool::ORequestThread having executed
a binaryurp::IncomingRequest holds the last binaryurp::Bridge reference:
> #2 0x00007fac4ad6bf97 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x7fac4b4e8c22 "false", file=file@entry=0x7fac4b4eaec7 "sal/osl/unx/thread.cxx", line=line@entry=443, function=function@entry=0x7fac4b4eaefd "void osl_joinWithThread(oslThread)") at assert.c:92
> #3 0x00007fac4ad6c042 in __GI___assert_fail (assertion=0x7fac4b4e8c22 "false", file=0x7fac4b4eaec7 "sal/osl/unx/thread.cxx", line=443, function=0x7fac4b4eaefd "void osl_joinWithThread(oslThread)") at assert.c:101
> #4 0x00007fac4b4d5258 in osl_joinWithThread(oslThread) (Thread=0x7fabfc0011d0) at sal/osl/unx/thread.cxx:443
> #5 0x00007fac47fbdde5 in cppu_threadpool::ThreadAdmin::join() (this=0x7fac1c0069e0) at cppu/source/threadpool/thread.cxx:89
> #6 0x00007fac47fc23af in cppu_threadpool::ThreadPool::joinWorkers() (this=<optimized out>) at cppu/source/threadpool/threadpool.cxx:179
> #7 0x00007fac47fc35b7 in uno_threadpool_destroy(uno_ThreadPool) (hPool=<optimized out>) at cppu/source/threadpool/threadpool.cxx:499
> #8 0x00007fac25b03b5c in binaryurp::Bridge::terminate(bool) (this=0x7fac24117078, final=true) at binaryurp/source/bridge.cxx:277
> #9 0x00007fac25b0794e in binaryurp::Bridge::dispose() (this=0x7fac24117078) at binaryurp/source/bridge.cxx:904
> #10 0x00007fac25b07215 in binaryurp::Bridge::~Bridge() (this=0x7fac24117078) at binaryurp/source/bridge.cxx:847
> #11 0x00007fac25b07409 in binaryurp::Bridge::~Bridge() (this=0x7fac24117078) at binaryurp/source/bridge.cxx:838
> #12 0x00007fac25b39ee1 in std::default_delete<binaryurp::IncomingRequest>::operator()(binaryurp::IncomingRequest*) const (this=<optimized out>, __ptr=0x7fabfc00ba50) at /usr/lib/gcc/x86_64-redhat-linux/6.2.1/../../../../include/c++/6.2.1/bits/unique_ptr.h:76
> #13 0x00007fac25b38fa8 in std::unique_ptr<binaryurp::IncomingRequest, std::default_delete<binaryurp::IncomingRequest> >::~unique_ptr() (this=0x7fac0bb74ac0) at /usr/lib/gcc/x86_64-redhat-linux/6.2.1/../../../../include/c++/6.2.1/bits/unique_ptr.h:236
> #14 0x00007fac25b36d71 in request(void*) (pThreadSpecificData=<optimized out>) at binaryurp/source/reader.cxx:83
> #15 0x00007fac47fbaa95 in cppu_threadpool::JobQueue::enter(long, bool) (this=<optimized out>, nDisposeId=<optimized out>, bReturnWhenNoJob=<optimized out>) at cppu/source/threadpool/jobqueue.cxx:107
> #16 0x00007fac47fbe1f9 in cppu_threadpool::ORequestThread::run() (this=0x7fabfc001160) at cppu/source/threadpool/thread.cxx:165
> #17 0x00007fac47fbf9ca in threadFunc(void*) (param=0x7fabfc001170) at include/osl/thread.hxx:185
> #18 0x00007fac4b4d5a3c in osl_thread_start_Impl(void*) (pData=0x7fabfc0011d0) at sal/osl/unx/thread.cxx:240
> #19 0x00007fac4ab2a5ca in start_thread (arg=0x7fac0bb75700) at pthread_create.c:333
> #20 0x00007fac4ae420ed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
while the main thread is already shutting down:
> #19 0x00007fac4b14100f in desktop::Desktop::doShutdown() (this=0x7fff8a6149d0) at desktop/source/app/app.cxx:1783
> #20 0x00007fac4b13f505 in desktop::Desktop::Main() (this=0x7fff8a6149d0) at desktop/source/app/app.cxx:1716
> #21 0x00007fac419a0f79 in ImplSVMain() () at vcl/source/app/svmain.cxx:185
> #22 0x00007fac419a1c14 in SVMain() () at vcl/source/app/svmain.cxx:223
> #23 0x00007fac4b17c773 in soffice_main() () at desktop/source/app/sofficemain.cxx:166
> #24 0x0000000000400916 in sal_main () at desktop/source/app/main.c:48
> #25 0x00000000004008fb in main (argc=<optimized out>, argv=<optimized out>) at desktop/source/app/main.c:47
Change-Id: I34beac40e89f6d522af49f9dcdb3ed2fc1259c4b
... except in include/rtl, include/sal, include/uno, where sal_Size is
retained for compatibility, and where callers of rtl functions pass in
pointers that are incompatible on MSVC.
Change-Id: I8344453780689f5120ba0870e44965b6d292450c
The issue of 362d4f0cd4 "Explicitly mark
overriding destructors as 'virtual'" appears to no longer be a problem with
MSVC 2013.
(The little change in the rewriting code of compilerplugins/clang/override.cxx
was necessary to prevent an endless loop when adding "override" to
OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager();
in chart2/source/inc/LifeTime.hxx, getting stuck in the leading
OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that
isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.)
Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
A ridiculously fast way of doing this is:
for i in $(pcregrep -l -M -r --include='.*[hc]xx$' \
--exclude-dir=workdir --exclude-dir=instdir '^
{3,}' .)
do
perl -0777 -i -pe 's/^
{3,}/
/gm' $i
done
Change-Id: Iebb93eccbee9e4fc5c4380474ba595858a27ac2c
Reviewed-on: https://gerrit.libreoffice.org/22224
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
