claims of python unit test un-debugability considered somewhat exaggerated

Michael Stahl mstahl at redhat.com
Fri Apr 5 14:44:17 PDT 2013


so i spent the day trying to understand soffice bootstrap and moving the
proposed Python unit tests in-process to see if that makes this more
acceptable for people.

https://gerrit.libreoffice.org/#/c/3215/

this runs inside gdb in the same way as the CppUnit ones:

> (cd sw && make subsequentcheck GDBCPPUNITTRACE="gdb --args")

with the necessary package installed for a system python3:

> su -c "debuginfo-install python3-3.3.0-1.fc18.x86_64"

it's possible to get real Python backtrace in gdb
(here the top of the C stack is the C++ API method
Desktop::loadComponentFromURL, called from python):

> (gdb) py-bt
> Traceback (most recent call first):
>   File "/work/lo/work/unotest/source/python/org/libreoffice/unotest.py", line 180, in openEmptyWriterDoc
>     self.xDoc = desktop.loadComponentFromURL("private:factory/swriter", "_blank", 0, loadProps)
>   File "./qa/unoapi/python/set_expression.py", line 13, in setUpClass
>     cls._xDoc = cls._unoCon.openEmptyWriterDoc()
>   File "/usr/lib64/python3.3/unittest/suite.py", line 143, in _handleClassSetUp
>     setUpClass()
>   File "/usr/lib64/python3.3/unittest/suite.py", line 97, in run
>     self._handleClassSetUp(test, result)
>   File "/usr/lib64/python3.3/unittest/suite.py", line 67, in __call__
>     return self.run(*args, **kwds)
>   File "/usr/lib64/python3.3/unittest/suite.py", line 105, in run
>     test(result)
>   File "/usr/lib64/python3.3/unittest/suite.py", line 67, in __call__
>     return self.run(*args, **kwds)
>   File "/usr/lib64/python3.3/unittest/suite.py", line 105, in run
>     test(result)
>   File "/usr/lib64/python3.3/unittest/suite.py", line 67, in __call__
>     return self.run(*args, **kwds)
>   File "/usr/lib64/python3.3/unittest/runner.py", line 168, in run
>     test(result)
>   File "/usr/lib64/python3.3/unittest/main.py", line 261, in runTests
>     self.result = testRunner.run(self.test)
>   File "/usr/lib64/python3.3/unittest/main.py", line 125, in __init__
>     self.runTests()
>   File "/usr/lib64/python3.3/unittest/__main__.py", line 12, in <module>
>     main(module=None)
>   File "/usr/lib64/python3.3/runpy.py", line 73, in _run_code
>     exec(code, run_globals)
>   File "/usr/lib64/python3.3/runpy.py", line 160, in _run_module_as_main
>     "__main__", fname, loader, pkg_name)

there are also commands to print python objects and local variables.

unfortunately one thing that i haven't found how to do is setting a
breakpoint in the python code from gdb... the best i've found is a lame
workaround of inserting a statement into the python code to send
yourself a signal, which is, well, a lame workaround:

>     os.kill(os.getpid(), signal.SIGUSR1)

i wonder if it would be possible to easily add something to gdb to make
the python debugging a bit more seamless?



More information about the LibreOffice mailing list