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