office-gobmx

History

Stephan Bergmann e7a3329fd0 DeInitVCL in PythonTest After `b9757f5cfd` "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 private_initTestEnvironment. 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 solenv/gbuild/PythonTest.mk. 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: Stephan Bergmann <sbergman@redhat.com>		2018-09-07 07:31:48 +02:00
..
demo
doc
inc
qa/pytests	DeInitVCL in PythonTest	2018-09-07 07:31:48 +02:00
source	DeInitVCL in PythonTest	2018-09-07 07:31:48 +02:00
zipcore
CustomTarget_python_shell.mk
CustomTarget_pyuno_pythonloader_ini.mk
Executable_python.mk
Library_pythonloader.mk
Library_pyuno.mk
Library_pyuno_wrapper.mk
Makefile
Module_pyuno.mk
Package_python_scripts.mk
Package_python_shell.mk
Package_pyuno_pythonloader_ini.mk
PythonTest_pyuno_pytests_insertremovecells.mk
PythonTest_pyuno_pytests_ssl.mk
PythonTest_pyuno_pytests_testcollections.mk
Rdb_pyuno.mk
README

README

UNO bindings for the Python programming language.

To have much joy debugging python extensions you need to:
  a) edit pythonloader.py in your install setting DEBUG=1 at the top
  b) touch pyuno/source/module/pyuno_runtime.cxx and 'make debug=true' in pyuno

Then you'll start to see your exceptions on the console instead of them getting
lost at the UNO interface.

Python also comes with a gdb script
libpython$(PYTHON_VERSION_MAJOR).$(PYTHON_VERSION_MINOR)m.so.1.0-gdb.py
that is copied to instdir and will be auto-loaded by gdb;
it provides commands like "py-bt" to get a python-level backtrace,
and "py-print" to print python variables.

Another way to debug Python code is to use pdb: edit some initialization
function to insert "import pdb; pdb.set_trace()" (somewhere so that it is
executed early), then run soffice from a terminal and a command-line python
debugger will appear where you can set python-level breakpoints.