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? _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
