[Libreoffice-commits] core.git: vcl/source

[Stephan Bergmann (via logerrit)]

 vcl/source/window/abstdlg.cxx |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

New commits:
commit dd6f59a52a564f470070063719d1e9ff2e814261
Author:     Stephan Bergmann <sbergman at redhat.com>
AuthorDate: Fri Sep 11 12:30:13 2020 +0200
Commit:     Stephan Bergmann <sbergman at redhat.com>
CommitDate: Fri Sep 11 14:09:12 2020 +0200

    Do not even unload cui library during exit
    
    <https://gerrit.libreoffice.org/c/core/+/102222> "Turn OUStringLiteral into a
    consteval'ed, static-refcound rtl_uString" kept crashing in UITest_sw_options:
    VclAbstractDialogFactory::Create loaded the cui library, then some code created
    OUString instances pointing at the
    
    > const OUStringLiteral VIEWOPT_DATANAME = u"page data";
    
    (cui/source/options/treeopt.cxx) in the cui library's rodata section, and at
    least one of those OUString instances ended up in the data structures
    owned by the static configmgr::Components singleton
    (configmgr/source/components.cxx).  Now the UITest_sw_options test code in
    sw/qa/uitest/options/tdf78133.py makes some modifications that apparently cause
    SvtLinguConfig (unotools/source/config/lingucfg.cxx) to be used but, for
    whatever reason (i.e., whether or not that is another bug that would benefit
    from chasing it down), not get cleaned up properly, so that during termination,
    
    > warn:unotools.config:799178:799178:unotools/source/config/configmgr.cxx:140: ConfigManager not empty
    
    gets emitted, and that SvtLinguConfig apparently holds on to configmgr data so
    that the configmgr::Components singleton data structures are not fully cleaned
    up prior to exit.
    
    So when the exit handlers run, they happened to be run in such an order that
    first this static aDialogLibrary was destroyed, causing the cui library (and its
    rodata segment) to be unloaded, and only then the static configmgr::Components
    singleton was destroyed.  The latter tried to remove all its not-yet-cleaned-up
    (see above) data structures, which still referenced an OUString instance
    containing a---meanwhile dangling---pointer to VIEWOPT_DATANAME, causing a
    crash.
    
    So instead of a static Module, use Module::release, as is already used in other
    places loading libraries.
    
    Change-Id: Ibc16d26f6125d20317a641b95ef71b4b406f0999
    Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102456
    Tested-by: Jenkins
    Reviewed-by: Stephan Bergmann <sbergman at redhat.com>

diff --git a/vcl/source/window/abstdlg.cxx b/vcl/source/window/abstdlg.cxx
index b774b0206f3e..7a75e8c439fb 100644
--- a/vcl/source/window/abstdlg.cxx
+++ b/vcl/source/window/abstdlg.cxx
@@ -33,12 +33,14 @@ VclAbstractDialogFactory* VclAbstractDialogFactory::Create()
 {
     static auto fp = []() -> FuncPtrCreateDialogFactory {
 #ifndef DISABLE_DYNLOADING
-        static ::osl::Module aDialogLibrary;
+        ::osl::Module aDialogLibrary;
         if (aDialogLibrary.loadRelative(&thisModule, CUI_DLL_NAME,
                                         SAL_LOADMODULE_GLOBAL | SAL_LOADMODULE_LAZY))
         {
-            return reinterpret_cast<FuncPtrCreateDialogFactory>(
+            auto const p = reinterpret_cast<FuncPtrCreateDialogFactory>(
                 aDialogLibrary.getFunctionSymbol( "CreateDialogFactory" ) );
+            aDialogLibrary.release();
+            return p;
         }
         return nullptr;
 #else