Created attachment 150320 [details] example code to reproduce DISCLAIMER: I don't know if this qualifies as a "bug" or not, but I think it does highlight a problem either with the framework or with users of the framework. This "problem" explains https://bugs.kde.org/show_bug.cgi?id=451059 SUMMARY KMainWindow saves the auto settings on various event. Most problematic is that it triggers a save on many visibility events: https://github.com/KDE/kdelibs/blob/1c5b25966136b6099665477616fb4d38a98fd7ef/kdeui/widgets/kmainwindow.cpp In most cases, this is not an issue except under this, unfortunately not uncommon, situation: switching virtual desktops of many windows using the same config file. More precisely, assume N windows of the same application (for example okular) are in a first desktop. All those windows share the same configuration file. If one switching virtual desktop for example, potentially all N windows will receive a visibility event notification. Hence all will trigger the setSettingsDirty(), which will launch a timeout that will eventually saveAutoSaveSettings(). This will .sync() on the autoSaveGroup. The sync() will all happen almost at the same time and, eventually, all N-1 of them will block in QLockFile trying to acquire a lock. The logic in QLockFile (qtbase/src/corelib/io/qlockfile.cpp) doubles the timer every times it fails. This means that in the unlucky, but not so rare event, where every process blocks, this will wait 2^N*100 ms. In practice, I have managed to reach more than 5 seconds freezes with 10 windows. There might be other ways the auto settings are saved, I think what I described above is correct, based on playing around with gdb. A caveat is that the settings are saved only if something changed (ie settings are dirty). Simply moving a window is sufficient. For a more complex UI such as the one used by okular, it seems that simply switching desktops is sufficient to makes settings dirty, I am not entirely sure why/how. To simplify the reproducibility of this problem, I have written a trivial application (attached). It runs a timer and measures when the timer is not called then prints a message. Since the saving codes runs on the main thread, blocking on QLockFile freezes the main thread and prevents from dispatching the timer event. STEPS TO REPRODUCE 1. compile the application: cmake -G 'Unix Makefiles' && make 2. run 10 copies of the application: for i in {1..10}; do ./example_bug& done 3. This should already print some very large delays, showing that the saving mecanism triggers some long waits 4. Manually move each of the windows 5. Switching to another virtual desktop and switch back 6. This should print some huge delays 7. close all windows: kilall example_bug OBSERVED RESULT Some windows freezes for 5seconds or more, here is the output: time elapsed: 212 ms time elapsed: 233 ms time elapsed: 285 ms time elapsed: 300 ms time elapsed: 384 ms time elapsed: 201 ms time elapsed: 387 ms time elapsed: 386 ms time elapsed: 406 ms time elapsed: 806 ms time elapsed: 1619 ms time elapsed: 3209 ms time elapsed: 6412 ms EXPECTED RESULT Windows should not freeze. ADDITIONAL INFORMATION I have not specified any version for Qt/KDE because based on the source code of kmainwindow, I suspect this has been an issue for a long time. Any recent version of Qt/KF5 will trigger this issue.
The link in your post is to a source file in kdelibs, which was split into multiple repos many years ago, kmainwindow.cpp is now in KXmlGui; do you see this problem with recent KF5 versions?
Yes, the problem occurs on my machine with KDE framework 5.94.0. Here is the link of the kmainwindow file that still contains the same code: https://github.com/KDE/kxmlgui/blob/master/src/kmainwindow.cpp