• Stephan Bergmann's avatar
    DeInitVCL in PythonTest · e7a3329f
    Stephan Bergmann yazdı
    After b9757f5c "loplugin:useuniqueptr in
    vcl/svdata" ASan/UBSan builds started to fail (like
    <https://ci.libreoffice.org//job/lo_ubsan/1025/>) at the end of
    PythonTest_dbaccess_python (and probably other PythonTests), when during exit
    the static utl::ConfigManager instance already happens to be destroyed by the
    time the static ImplSVData's mpSettingsConfigItem is destroyed (which would
    normally be cleared during DeInitVCL, if PythonTests would call that, and which
    in the past had thus simply been leaked in PythonTests when that
    mpSettingsConfigItem was a plain pointer instead of std::unique_ptr).
    So ensure that PythonTests that initialize VCL also call DeInitVCL, via a new
    private_deinitTestEnvironment, complementing the existing
    However, while private_initTestEnvironment is called once (typically via
    UnoInProcess.setUp, which internally makes sure to only call it once) as soon as
    the first executed test needs it, private_deinitTestEnvironment must be called
    once after the lasts test needing it has executed.  The only way that I found to
    do that is to override unittest.TextTestResult's stopTestRun method, which is
    called once after all tests have been executed.  Hence a new test runner setup
    in unotest/source/python/org/libreoffice/unittest.py that is now called from
    That revealed a few places in PythonTests that didn't yet close/delete documents
    that they had opened, which has now been added.
    One remaining problem then is that classes like SwXTextDocument and friends call
    Application::GetSolarMutex from their dtors, via sw::UnoImplPtrDeleter (a "Smart
    pointer class ensuring that the pointed object is deleted with a locked
    SolarMutex", sw/inc/unobaseclass.hxx).  That means that any PyUNO proxies to
    such C++ objects that remain alive after private_deinitTestEnvironment will
    cause issues at exit, when Python does a final garbage collection of those
    objects.  The ultimate fix will be to remove that unhelpful UnoImplPtrDeleter
    and its locking of SolarMutex from the dtors of UNO objects; until then, the
    Python code is now sprinkled with some HACKs to make sure all those PyUNO
    proxies are released in a timely fashion (see the comment in
    unotest/source/python/org/libreoffice/unittest.py for details).  (Also, it would
    probably help if UnoInProcess didn't keep a local self.xDoc around referencing
    (just) the last result of calling one of its open* methods, confusingly making
    it the responsibility of UnoInProcess to close that one document while making it
    the responsibility of the test code making the other UnoInProcess.open* calls to
    close any other documents.)
    Change-Id: Ief27c81e2b763e9be20cbf3234b68924315f13be
    Reviewed-on: https://gerrit.libreoffice.org/60100
    Tested-by: Jenkins
    Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
testcollections_XEnumerationAccess.py 3.46 KB