Bug 92529 - config written during startup ...
Summary: config written during startup ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: framework (show other bugs)
(earliest affected)
Hardware: Other All
: medium normal
Assignee: Not Assigned
Keywords: difficultyMedium, easyHack, skillCpp, topicCleanup
Depends on:
Blocks: Too-Much-File-Access
  Show dependency treegraph
Reported: 2015-07-03 16:40 UTC by Michael Meeks
Modified: 2020-10-27 05:41 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Michael Meeks 2015-07-03 16:40:06 UTC
This looks (at least to the un-trained eye) somewhat odd.

--- a/configmgr/source/components.cxx
+++ b/configmgr/source/components.cxx
@@ -167,6 +167,7 @@ Components::WriteThread::WriteThread(
     Thread("configmgrWriter"), reference_(reference), components_(components),
     url_(url), data_(data)
+    SAL_DEBUG("*** create write thread ***");
     lock_ = lock();
     assert(reference != 0);
@@ -177,6 +178,7 @@ void Components::WriteThread::execute() {
     osl::MutexGuard g(*lock_); // must not throw
     try {
         try {
+            SAL_DEBUG("*** write config  ***");
             writeModFile(components_, url_, data_);
         } catch (css::uno::RuntimeException & e) {
             // Ignore write errors, instead of aborting:

Starting libreoffice, launching writer and exiting produces:

debug:5743:1: *** create write thread ***!
debug:5743:2: *** write config  ***!
debug:5743:1: *** create write thread ***!
debug:5743:7: *** write config  ***!
debug:5743:1: *** create write thread ***!
debug:5743:8: *** write config  ***!
debug:5743:1: *** create write thread ***!
debug:5743:9: *** write config  ***!

Which seems quite a lot given the lack of any user-initiated settings change.
Comment 1 Michael Meeks 2015-07-03 16:41:06 UTC
Stephan - do you expect that ? prolly a total non-issue, but looks odd =)
Comment 2 Stephan Bergmann 2015-07-06 07:12:40 UTC
The way it works is that every call to the configmgr's commitChanges() initiates a write-back of registrymodifcations.xcu.  Actual writing is then delayed by 1 second to allow consecutive calls to commitChanges() to pile up and be processed in one batch.

That is, this needs looking at the client code that calls commitChanges() (configmgr/source/readwriteaccess.cxx) to determine why there is so much activity.  (I assume it is about storing window positions and such.)

(Also, the configmgr code does not remember which values it originally read in from registrymodifications.xcu, so that it cannot detect cases where the changes committed by client code would not change the existing registrymodifcations.xcu, and optimize those writes away.  The assumption is that client code does not trigger such "unnecessary non-changes.")
Comment 3 Michael Meeks 2015-07-06 16:16:27 UTC
Fair cop - so I'l easy-hack-ize this. The task would be (I guess) to catch and unwind commitChanges() calls during startup that are writing redundant data, and also (ideally) to defer config write-back until after startup has completed - my hope being that we call an explicit flush_() that short-circuits that timeout if we exit.

I guess we'd want to hook that into desktop/source/app/ via some new API on any non-published interface implemented by (probably):


Or - I guess we could overload the semantic of 'flush' there - such that we start out with a much longer timeout to write-back say 10seconds or so - and we reset that on the first flush() - might work better ;-) 

Thanks ! =)
Comment 4 Stephan Bergmann 2015-07-07 08:42:44 UTC
(In reply to Michael Meeks from comment #3)
> Fair cop - so I'l easy-hack-ize this. The task would be (I guess) to catch
> and unwind commitChanges() calls during startup that are writing redundant
> data, and also (ideally) to defer config write-back until after startup has
> completed - my hope being that we call an explicit flush_() that
> short-circuits that timeout if we exit.

Keep it simple.  First, find out what actually triggers those four writes, and whether they are during startup or shutdown or inbetween.  Only then, think about any changes, if necessary.
Comment 5 Chris Halls 2015-09-09 13:50:07 UTC
There's another use case that is relevant to this code in this Debian bug report:

 Bug#774399: libreoffice: aggressive (blocking) config rewrite (lag, slowness)

"With /home on network file system (NFS or similar) libreoffice is lagging 
miserably on basic operations like when libreoffice just started or new writer 
document is opened etc., as well as on innocent moves between tabs under 
[Tools -> Options -> Libreoffice] even when nothing is changed."
Comment 6 Stephan Bergmann 2015-09-09 14:24:56 UTC
(In reply to Chris Halls from comment #5)

(1)  While writing the configuration changes happens asynchronously in its own thread, it does lock a configuration-wide mutex, so other threads trying to access the configuration can get blocked.

(2)  What may already help the performance of some use cases (though probably not the above NFS case) is <http://cgit.freedesktop.org/libreoffice/core/commit/?id=e1d78e123b74d37f95b4075b93202b023b4320e9> "tdf#92764 - make configmgr write less noisy."

(3)  Re "An ugly workaround may be to disable configuration changes completely by setting profile folder read-only" (<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774399#5>):  Since <http://cgit.freedesktop.org/libreoffice/core/commit/?id=12f92e6d9ea8bf05bda6d3c42f9b6f0aba000cb0> "Support modification write-back to other than registrymodifications.xcu," you can change the "user:" entry in LO's fundamentalrc CONFIGURATION_LAYERS line from "user:..." (or "user:!...") to "user:*..." to not write any new updates to registrymodifications.xcu (but still read in an already existing one on startup).  (And on older versions, just removing the "user:" entry from CONFIGURATION_LAYERS should work to not read nor write registrymodifications.xcu).  For better or worse.
Comment 7 Robinson Tryon (qubit) 2015-12-10 11:41:03 UTC Comment hidden (obsolete)
Comment 8 Robinson Tryon (qubit) 2016-02-18 14:51:30 UTC Comment hidden (obsolete)
Comment 9 Komal 2018-12-29 15:08:41 UTC
Hi Michael, I am Komal. I am novice to open source. But really interested to learn and contribute for this organization.Would like to work on this issue? I need help, as to how do I go about it?
Thank you!
Comment 10 Komal 2018-12-31 12:49:44 UTC Comment hidden (obsolete)
Comment 11 Stephan Bergmann 2019-01-02 08:54:21 UTC
(In reply to Komal from comment #10)
> Hey Stephan, Is this issue still open? Can you help me in resolving it?

The configmgr entry point for comment 4 is RootAccess::commitChanges in configmgr/source/rootaccess.cxx, which calls Components::writeModifications in configmgr/source/components.cxx to actually spawn the asynchronous write-back thread.  What's relevant here is to find out why RootAccess::commitChanges is already called during start up.