Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index



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?


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.