...seen at least with gcc-15.1.1-2.fc42.x86_64, when doing optimizing LO builds,
> In file included from include/rtl/ustring.h:29,
> from include/typelib/typedescription.h:29,
> from include/com/sun/star/uno/Type.h:26,
> from workdir/UnoApiHeadersTarget/udkapi/normal/com/sun/star/beans/Property.hdl:6,
> from workdir/UnoApiHeadersTarget/udkapi/normal/com/sun/star/beans/Property.hpp:6,
> from configmgr/source/access.cxx:28:
> In member function ‘void configmgr::Access::releaseNondeleting()’,
> inlined from ‘rtl::Reference<configmgr::ChildAccess> configmgr::Access::getUnmodifiedChild(const rtl::OUString&)’ at configmgr/source/access.cxx:2064:38:
> include/osl/interlck.h:91:57: error: ‘unsigned int __sync_sub_and_fetch_4(volatile void*, unsigned int)’ writing 4 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
> 91 | # define osl_atomic_decrement(p) __sync_sub_and_fetch((p), 1)
> | ~~~~~~~~~~~~~~~~~~~~^~~~~~~~
> configmgr/source/access.cxx:134:5: note: in expansion of macro ‘osl_atomic_decrement’
> 134 | osl_atomic_decrement(&m_refCount);
> | ^~~~~~~~~~~~~~~~~~~~
> In member function ‘rtl::Reference<configmgr::ChildAccess> configmgr::Access::getUnmodifiedChild(const rtl::OUString&)’:
> cc1plus: note: destination object is likely at address zero
Change-Id: I0885af282844fecaf4c117df7d24a943b62aa42c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188259
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Ever since 21d42ab495 "#75148# check security and
netaccess are set now", getJavaPropsFromSafetySettings in
stoc/source/javavm/javavm.cxx tries to read a Security property (of type
xs:boolean in officecfg/registry/schema/org/openoffice/Office/Java.xcs) via
XRegistryKey::getLongValue. While this may have worked with the previous
configmgr implementation, it now just always caused an exception (that would
have been swalled in initVMConfiguration in stoc/source/javavm/javavm.cxx).
Not sure if there are any other places where code expects to read a boolean
property value from the configuration via XRegistryKey::getLongValue, but lets
better add that (back) as a (hopefully) harmless extension.
Change-Id: I33ca60595da8fd79fb9250d74f36be0b328d610f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183269
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
some properties, e.g. the localized user strings for "uno commands"
as used by vcl::CommandInfoProvider::GetCommandProperties are
cloned, so the inserted clones are not staticized.
Profiles persisted in show many probe:do_wp_page events from
salhelper::SimpleReferenceObject::acquire in
configmgr::Access::getUnmodifiedChild
https: //raw.githubusercontent.com/caolanm/profiles/585ce8645ff6ea1e3de1b3cc6f11a16f325fb0d9/do_wp_page/Demo.eu-2025-02-12T04%3A36%3A21.759836.svg
Change-Id: I3eaccbbd7e9af0c312ed1d7da68e64ffb96d3292
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181513
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 9be96cfcaec84b730ad2dae923a91aa39efe2993)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182350
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Profiles show lots of probe:do_wp_page events from things like
configmgr::Access::getUnmodifiedChild - as when we read we touch
lots of Node reference counts - un-necessarily.
So - reduce un-necessary reference counting thrash here in the
lok case through the environment variable. Quite possibly this
would also be safe and beneficial for the desktop app - needs
measurement.
measuring with coolmap and an empty hello-world.odt before & after:
before:
unshared 3634 (14536kB)
unshared 3631 (14524kB)
unshared 3605 (14420kB)
after:
unshared 3578 (14312kB)
unshared 3613 (14452kB)
unshared 3599 (14396kB)
Not hugely encouraging, perhaps there is another page touch
underneath we'll find when this is addressed.
Change-Id: I8ac74c5fcd17f8699139e914a7076a7848456e2a
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175197
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182349
Tested-by: Jenkins
We use the same funciton all over the place, so create a common
function in o3tl and use that in all instances where we duplicated
the code.
Change-Id: I74091fbbde8c2ba8c7e4ab30194ab53e2a338e52
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180372
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
insertModificationXcuFile takes a set of paths to include and a set of
paths to ignore from a given .xcu files
adapt this to allow an include path of "/" to match all contents of the
xcu.
insertModificationXcuFile is more useful than insertExtensionXcuFile for
the intended use case, because the latter inserts as an extension level
layer, and cannot override higher layers.
Change-Id: I8eabd9fb91184146a75b087cc31cee44f378d96d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178603
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
When there are multiple competing configuration settings for the same
configuration layer (e.g., in xcu files of two different extensions from the
same extension layer), then the setting that is read last always won, even if
any of the settings read earlier is marked as finalized. (The reason for
originally doing it that way was that it kept the code logic somewhat simple.)
However, esp. for a scenario of multiple extensions in one extension layer
(bundled, shared, or user), it can be unexpected by a user that a non-finalized
setting (that comes from the extension that happens to be read last) can win
over a finalized one.
Therefore, change the logic accordingly. Now, if any of the competing settings
are finalized, the first finalized one that is read wins.
Change-Id: I22aeade543a5b26d95d49cfcb561f974cd7a5081
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177737
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
I don't think anyone is getting around to changing this after 13
years, and an int worth of config layers looks safe enough to me.
Change-Id: Iecf00a4d342e60d8f56a27978c40fa8d861ecd7e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177428
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
... otherwise the unotools/source/config/configitem.cxx
ConfigItem::impl_packLocalizedProperties() checking for
(getValueTypeName() == "com.sun.star.uno.XInterface") would not
hit and thus not pack the properties, returning just the useless
XWeak pointer as property.
This in ScUnoAddInCollection::ReadConfiguration() lead to English
names not being extracted from configured Add-Ins' DisplayName or
CompatibilityName, nor any CompatibilityName added to the list.
Fallout from
commit bc70f674c2
CommitDate: Sun Jun 18 08:41:27 2023 +0200
Use getXWeak in configmgr
Change-Id: Ibaab8c08a06113b27ceffe1c45ef548c1d6fa225
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172476
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
...instead of joining and later re-spawning one. This helps with the current
Emscripten setup (see 5b1df7709d "Document the
Emscripten threads issue"), and probably doesn't matter much either way on other
platforms (so just get it in unconditionally). (Renaming the delay_ member
variable to delayOrTerminate_, to make its overall role more clear.)
(I ran into this when trying to turn the Emscripten build from starting up with
a Writer document to starting up with the start center, and then manually
opening a new Writer document. The resulting different usage scheme happened to
exhaust our current -sPTHREAD_POOL_SIZE=4 pool quickly, so this is one of
multiple commits to address that.)
Change-Id: I1bd28604b4640d2afad982bfd82b1acee8200e26
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170993
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
That code had been added with 9fa4eff9be
"profilesafe: Enhancements to BackupFileHelper", but it looks dubious:
For one, I cannot find proof for the claim that MSVC would run destructors of
static objects upon _exit. Building a simple C++ test program
> #include <iostream>
> #include <stdlib.h>
> struct S { ~S() { std::cerr << "hello\n"; } };
> S s;
> void f() { _exit(1); }
> int main() { f(); }
with contemporary MSVC 17.10 and executing it shows no "hello" stderr output
(see
<https://gcc.godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(filename:'1',fontScale:14,fontUsePx:'0',j:1,lang:c%2B%2B,selection:(endColumn:13,endLineNumber:5,positionColumn:13,positionLineNumber:5,selectionStartColumn:13,selectionStartLineNumber:5,startColumn:13,startLineNumber:5),source:'%23include+%3Ciostream%3E%0A%23include+%3Cstdlib.h%3E%0Astruct+S+%7B+~S()+%7B+std::cerr+%3C%3C+%22hello%5Cn%22%3B+%7D+%7D%3B%0AS+s%3B%0Avoid+f()+%7B+_exit(1)%3B+%7D%0Aint+main()+%7B+f()%3B+%7D%0A'),l:'5',n:'1',o:'C%2B%2B+source+%231',t:'0')),k:32.19670284753087,l:'4',m:100,n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:vcpp_v19_40_VS17_10_x64,filters:(b:'0',binary:'1',binaryObject:'1',commentOnly:'0',debugCalls:'1',demangle:'0',directives:'0',execute:'0',intel:'0',libraryCode:'0',trim:'1',verboseDemangling:'0'),flagsViewOpen:'1',fontScale:14,fontUsePx:'0',j:1,lang:c%2B%2B,libs:!(),options:'',overrides:!(),selection:(endColumn:1,endLineNumber:1,positionColumn:1,positionLineNumber:1,selectionStartColumn:1,selectionStartLineNumber:1,startColumn:1,startLineNumber:1),source:1),l:'5',n:'0',o:'+x64+msvc+v19.40+VS17.10+(Editor+%231)',t:'0'),(h:output,i:(compilerName:'x86-64+clang+18.1.0',editorid:1,fontScale:14,fontUsePx:'0',j:1,wrap:'1'),l:'5',n:'0',o:'Output+of+x64+msvc+v19.40+VS17.10+(Compiler+%231)',t:'0')),k:67.80329715246913,l:'4',m:100.00000000000001,n:'0',o:'',s:1,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4>).
If there indeed were issues with MSVC and non-standard _exit, a solution might
be to use standard _Exit instead (in FatalError in desktop/source/app/app.cxx).
And for another, when bExitWasCalled was true in
configmgr::Components::~Components, it would still have called
writeThread_->join() (i.e., it would potentially still have called
writeModFile from within configmgr::Components::WriteThread::execute()), but (a)
only after waiting out its full
> delay_.wait(std::chrono::seconds(1));
(because it missed to call configmgr::Components::WriteThread::flush, which
calls delay_.set()), and (b) potentially running into a deadlock because it
called writeThread_->join() with *lock_ locked, which
configmgr::Components::WriteThread::execute wants to lock too.
(I came across this because it got into my way when trying to adapt the
lifecycle of configmgr::Components::WriteThread to the needs of the Emscripten
build.)
Change-Id: Icb4ebf00d1d316b80c29f7bd91b86614ef4ac430
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170940
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
This reverts commit 154b204010, which is known
broken, as (unlike for boost::unordered_map) there is no guarantee that
std::unordered_map works for incomplete value types, and indeed there is build
environments that started to fail now with
> In file included from /home/libo/src/core/configmgr/source/partial.cxx:23:
> In file included from /usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/set:60:
> In file included from /usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/stl_tree.h:63:
> In file included from /usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/stl_algobase.h:64:
> /usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/stl_pair.h:218:11: error: field has incomplete type 'configmgr::Partial::Node'
> _T2 second; ///< The second member
> ^
[...]
Change-Id: Ie8d041bcf3d3b1b6aeede73adbaf14676250c4bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170467
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
std::multiset seems to be pretty slow to construct and
destruct, even if we ~never put anything into these listener
lists, so rather use o3tl::sorted_vector, which has more
predictable performance.
Shaves 10% off startup time for me.
Change-Id: I13afcbe3cb63522e4efe61c64f773e1ffbec9683
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167101
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The unused but valid child elements of <info> such as <author> may be
used by exentions. This fails with:
warn:configmgr:15104:10916:configmgr/source/components.cxx:660: error reading "file:///instdir/program/../share/uno_packages/cache/uno_packages/....xcs" com.sun.star.uno.RuntimeException message: "bad member <component> in ....xcs at configmgr/source/xcsparser.cxx:289"
Because ending the first such element sets bIsParsingInfo_ to false.
This fix just concatenates all the characters in all the children,
should work well enough for extensions.
(regression from commit db3078bd8c)
Change-Id: I17a3fb7014cd34c1d546701036550085365432a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165143
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
...which each pertain to all the preceding code that extracts numbers from
strings, and where 0a5d4dc25c "elide some OString
temporaries" had changed that preceding code from stretching over a single to
stretching over multiple statements each
Change-Id: I315187465d64f620b1ddea8a0cc74ed5f8dc113b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163063
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...to reflect whether or not the corresponding item can be modified. Which
matches what the READONLY flag is actually used for today. (And the original,
somewhat arbitrary semantics had been assigned without much thought, IIRC, and
it should be OK to change them.)
Change-Id: I8185e47519a5cb4aff6e8f260326845276b0c092
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160957
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Michael Weghorn