the appearance of 2 interceptions is reproducible for me on linux with
make CppunitTest_framework_dispatch VALGRIND=memcheck
1st time
#1 (anonymous namespace)::MyInterceptor::queryDispatch(com::sun:⭐:util::URL const&, rtl::OUString const&, int) at core/framework/qa/cppunit/dispatchtest.cxx:139
#2 non-virtual thunk to (anonymous namespace)::MyInterceptor::queryDispatch(com::sun:⭐:util::URL const&, rtl::OUString const&, int) at core/framework/qa/cppunit/dispatchtest.cxx:0
#3 framework::InterceptionHelper::queryDispatch(com::sun:⭐:util::URL const&, rtl::OUString const&, int) at core/framework/source/dispatch/interceptionhelper.cxx:87
#4 non-virtual thunk to framework::InterceptionHelper::queryDispatch(com::sun:⭐:util::URL const&, rtl::OUString const&, int) at core/framework/source/dispatch/interceptionhelper.cxx:0
#5 (anonymous namespace)::XFrameImpl::queryDispatch(com::sun:⭐:util::URL const&, rtl::OUString const&, int) at core/framework/source/services/frame.cxx:2329
#6 non-virtual thunk to (anonymous namespace)::XFrameImpl::queryDispatch(com::sun:⭐:util::URL const&, rtl::OUString const&, int) at core/framework/source/services/frame.cxx:0
#7 framework::DispatchHelper::executeDispatch(com::sun:⭐:uno::Reference<com::sun:⭐:frame::XDispatchProvider> const&, rtl::OUString const&, rtl::OUString const&, int, com::sun:⭐:uno::Sequence<com::sun:⭐🫘:PropertyValue> const&) at core/framework/source/services/dispatchhelper.cxx:110
#8 non-virtual thunk to framework::DispatchHelper::executeDispatch(com::sun:⭐:uno::Reference<com::sun:⭐:frame::XDispatchProvider> const&, rtl::OUString const&, rtl::OUString const&, int, com::sun:⭐:uno::Sequence<com::sun:⭐🫘:PropertyValue> const&) at core/framework/source/services/dispatchhelper.cxx:0
#9 unotest::MacrosTest::dispatchCommand(com::sun:⭐:uno::Reference<com::sun:⭐:lang::XComponent> const&, rtl::OUString const&, com::sun:⭐:uno::Sequence<com::sun:⭐🫘:PropertyValue> const&) at core/unotest/source/cpp/macros_test.cxx:94
#10 (anonymous namespace)::testInterception::TestBody() at core/framework/qa/cppunit/dispatchtest.cxx:172
2nd time
#1 (anonymous namespace)::MyInterceptor::queryDispatch(com::sun:⭐:util::URL const&, rtl::OUString const&, int) at core/framework/qa/cppunit/dispatchtest.cxx:139
#2 non-virtual thunk to (anonymous namespace)::MyInterceptor::queryDispatch(com::sun:⭐:util::URL const&, rtl::OUString const&, int) at core/framework/qa/cppunit/dispatchtest.cxx:0
#3 framework::InterceptionHelper::queryDispatch(com::sun:⭐:util::URL const&, rtl::OUString const&, int) at core/framework/source/dispatch/interceptionhelper.cxx:87
#4 non-virtual thunk to framework::InterceptionHelper::queryDispatch(com::sun:⭐:util::URL const&, rtl::OUString const&, int) at core/framework/source/dispatch/interceptionhelper.cxx:0
#5 (anonymous namespace)::XFrameImpl::queryDispatch(com::sun:⭐:util::URL const&, rtl::OUString const&, int) at core/framework/source/services/frame.cxx:2329
#6 non-virtual thunk to (anonymous namespace)::XFrameImpl::queryDispatch(com::sun:⭐:util::URL const&, rtl::OUString const&, int) at core/framework/source/services/frame.cxx:0
#7 SfxStateCache::GetSlotServer(SfxDispatcher&, com::sun:⭐:uno::Reference<com::sun:⭐:frame::XDispatchProvider> const&) at core/sfx2/source/control/statcach.cxx:263
#8 SfxBindings::UpdateSlotServer_Impl() at core/sfx2/source/control/bindings.cxx:1083
#9 SfxBindings::NextJob_Impl(Timer const*) at core/sfx2/source/control/bindings.cxx:1254
#10 SfxBindings::NextJob(Timer*) at core/sfx2/source/control/bindings.cxx:1222
#11 SfxBindings::LinkStubNextJob(void*, Timer*) at core/sfx2/source/control/bindings.cxx:1219
#12 Link<Timer*, void>::Call(Timer*) const at core/include/tools/link.hxx:111
#13 Timer::Invoke() at core/vcl/source/app/timer.cxx:76
#14 Scheduler::CallbackTaskScheduling() at core/vcl/source/app/scheduler.cxx:480
#15 SalTimer::CallCallback() at core/vcl/inc/saltimer.hxx:55
#16 SvpSalInstance::CheckTimeout(bool) at core/vcl/headless/svpinst.cxx:161
#17 SvpSalInstance::ImplYield(bool, bool) at core/vcl/headless/svpinst.cxx:399
#18 SvpSalInstance::DoYield(bool, bool) at core/vcl/headless/svpinst.cxx:471
#19 ImplYield(bool, bool) at core/vcl/source/app/svapp.cxx:377
#20 Scheduler::ProcessEventsToIdle() at core/vcl/source/app/svapp.cxx:407
#21 unotest::MacrosTest::dispatchCommand(com::sun:⭐:uno::Reference<com::sun:⭐:lang::XComponent> const&, rtl::OUString const&, com::sun:⭐:uno::Sequence<com::sun:⭐🫘:PropertyValue> const&) at core/unotest/source/cpp/macros_test.cxx:95
#22 (anonymous namespace)::testInterception::TestBody() at core/framework/qa/cppunit/dispatchtest.cxx:172
setting bold/italic will invalidate the slot for the property and timer
starts to update the normal listeners to those properties which might
kick in on a slower run.
Change-Id: Ib37e61c0fbed463f8974d476158e54a0160a2c92
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157798
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
I see occasional failures here, possibly they are a threading
issue since we are touching these fields from multiple threads.
Add a mutex to see if it helps.
Change-Id: I7277e96d07d292a6bc1d333dabec7a82fc607465
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150281
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
... rather than scheme: and path.
Change-Id: I9a48310b585b8fa3e31635f877a91f1560b065f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128457
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The scenarios are:
1. Calling sequence's begin() and end() in pairs to pass to algorithms
(both calls use getArray(), which does the COW checks)
2. In addition to #1, calling end() again when checking result of find
algorithms, and/or begin() to calculate result's distance
3. Using non-const sequences in range-based for loops, which internally
do #1
4. Assigning sequence to another sequence variable, and then modifying
one of them
In many cases, the sequences could be made const, or treated as const
for the purposes of the algorithms (using std::as_const, std::cbegin,
and std::cend). Where algorithm modifies the sequence, it was changed
to only call getArray() once. For that, css::uno::toNonConstRange was
introduced, which returns a struct (sublclass of std::pair) with two
iterators [begin, end], that are calculated using one call to begin()
and one call to getLength().
To handle #4, css::uno::Sequence::swap was introduced, that swaps the
internal pointer to uno_Sequence. So when a local Sequence variable
should be assigned to another variable, and the latter will be modified
further, it's now possible to use swap instead, so the two sequences
are kept independent.
The modified places were found by temporarily removing non-const end().
Change-Id: I8fe2787f200eecb70744e8b77fbdf7a49653f628
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123542
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This can be created either from the global SfxApplication, or from a
SfxViewFrame.
Particularly in the latter case, the SfxDispatcher and SfxBindings
members are owned by SfxViewFrame, so in case that is destroyed, the
SfxOfficeDispatch must clear its pointers.
It looks like the member pointers are checked before access already
everywhere, so just listen at the SfxViewFrame.
Change-Id: If08825734e94dd54e32cb77546684fd583c336ec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118162
Tested-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
MacrosTest::loadFromDesktop itself asserts on its return value.
Thus, the additional checks in unit tests are redundant, and only create
noise unrelated to the tested functionality.
Change-Id: If616001b296afdde38f5a23ececee3d44b4a395d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111290
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
See the comment at the top of compilerplugins/clang/stringliteralvar.cxx for
details.
(Turned some affected variables in included files into inline variables, to
avoid GCC warnings about unused variables.)
Change-Id: Ie77219e6adfdaaceaa8b4e590b08971f2f04c83a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
If the document loading is long enough that the statusbar is updated,
then we can have this situation that we start loading the document, then
spin the main loop during load and do a second load of the same document
as part of the main loop spinning:
#0 SwDoc::SwDoc() (this=0x1c6a180) at sw/source/core/doc/docnew.cxx:194
...
#6 0x00007ffff359a6dd in SfxBaseModel::load(com::sun:⭐:uno::Sequence<com::sun:⭐🫘:PropertyValue> const&) (this=0x1c5c260, seqArguments=uno::Sequence of length 15 = {...})
...
#33 0x00007fffeeb81ecd in Application::Reschedule(bool) (i_bAllEvents=true) at vcl/source/app/svapp.cxx:460
...
#36 0x00007ffff4265251 in framework::StatusIndicator::start(rtl::OUString const&, int) (this=0x1aace80, sText="Loading document...", nRange=1000000) at framework/source/helper/statusindicator.cxx:51
#37 0x00007fffd026dfd3 in XMLReader::Read(SwDoc&, rtl::OUString const&, SwPaM&, rtl::OUString const&) (this=0x1bb7d20, rDoc=..., rBaseURL="file:///.../test.odt", rPaM=SwPaM = {...}, rName="") at sw/source/filter/xml/swxml.cxx:630
...
#42 0x00007ffff359a6dd in SfxBaseModel::load(com::sun:⭐:uno::Sequence<com::sun:⭐🫘:PropertyValue> const&) (this=0x1bce4d0, seqArguments=uno::Sequence of length 15 = {...}) at sfx2/source/doc/sfxbasemodel.cxx:1883
The reason for this is is that by the time
LoadEnv::impl_searchAlreadyLoaded() searches for frames which already
have this doc open, the first load is still in progress, and we
assiciate the frame with its controller (which has the URL) only once
the load finishes.
Fix the problem by setting the URL on the frame directly for the
duration of the load: this way an in-progress load also counts as a
duplicate and we'll have just one document open at the end.
Regression from commit 74ac65c49c
(#i114963# Enable IPC before OpenClients to allow client connections
when printing., 2016-09-06), we just didn't process incoming requests on
the socket before, so the problem was less visible.
Change-Id: Ib138c4c264e2508c20104ab268501bcca31e2790
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104310
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Regression from commit 2dc3a6c273
(framework: allow loading a component on the main thread, 2018-12-19),
which was a forward-port from a 5.4-based vendor branch, where this was
(it turns out) just working by accident, but never on master.
It can happen that loadComponentFromURL() is invoked on a thread, which
does not own the solar mutex. Then once
vcl::SolarThreadExecutor::execute() is called, it'll try to release the
solar mutex. But SolarMutexReleaser is unsafe: it'll release the mutex
even if it is owned by an other thread.
To make this a bit more safer, it'll abort in
comphelper::SolarMutex::doRelease(), in case the current thread doesn't
have the mutex already.
Fix the problem by taking the solar mutex in loadComponentFromURL():
this is meant to cause no performance problems, since the actual
importers typically start with taking the solar mutex anyway. Taking it
earlier would be problematic, since this can be invoked by UNO clients
directly. Taking it later in vcl/ would be also unusual: typically vcl
just asserts that the solar mutex is locked, doesn't take it itself.
Change-Id: I752006a91f16a02254d1b5ac6301100ab282630b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103264
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
I added these files more or less recently and they have long lines. Use
clang-format to break at a sane column limit.
Change-Id: Id608fffbbc0673c9bc350dd696cb0a31906840d3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94423
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
look for places we are doing code like:
Reference<XProperty>(model, css::uno::UNO_QUERY)->getAsProperty()
which might result in a SIGSEGV is the query fails
Change-Id: I5cbdbc9e64bd0bed588297c512bf60cbacb9442e
Reviewed-on: https://gerrit.libreoffice.org/69044
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ice2eb8c5994bf2ccb88972332ca4a1d3ed41752a
Reviewed-on: https://gerrit.libreoffice.org/63826
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
with 506cab1a01
"take the .ui files from $BRAND_BASE_DIR/$BRAND_SHARE_SUBDIR"
in place .ui files are found and the count here changes,
reverting the above makes it pass, but also reverting
08cf2fd010 (framework: last dispatchInterceptor
gets asked first, 2016-05-20) that this test wants to test also passes
Change-Id: I01f5b77065e9562619412824bf69494b7b672b68
...(for now, from LIBO_INTERNAL_CODE only). See the mail thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html>
"Dynamic Exception Specifications" for details.
Most changes have been done automatically by the rewriting loplugin:dynexcspec
(after enabling the rewriting mode, to be committed shortly). The way it only
removes exception specs from declarations if it also sees a definition, it
identified some dead declarations-w/o-definitions (that have been removed
manually) and some cases where a definition appeared in multiple include files
(which have also been cleaned up manually). There's also been cases of macro
paramters (that were used to abstract over exception specs) that have become
unused now (and been removed).
Furthermore, some code needed to be cleaned up manually
(avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no
configurations available that would actually build that code. Missing @throws
documentation has not been applied in such manual clean-up.
Change-Id: I3408691256c9b0c12bc5332de976743626e13960
Reviewed-on: https://gerrit.libreoffice.org/33574
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
