Re: claims of python unit test un-debugability considered somewhat exaggerated
On Wed, 2013-04-10 at 01:45 +0200, David Ostrovsky wrote: On Tue, 2013-04-09 at 11:26 -0400, David Malcolm wrote: [...snip...] http://docs.python.org/devguide/gdb.html#gdb-7-and-later In particular: (gdb) py-list should give you python source code for the current python frame. Works like a charm here on OpenSUSE 12.3 too, with system python3.3: [...snip...] Good to hear. I must be missing something, but i didn't find a standard way how to install Tools/gdb/libpython.py from cpython, so i just cloned the upstream python, with hg clone http://hg.python.org/cpython and borrowed that lib from there (sourcing it manually on gdb): cpython/Tools/gdb/libpython.py You can grab that file directly from hg using: http://hg.python.org/cpython/raw-file/default/Tools/gdb/libpython.py (where the default means the default branch i.e. the trunk for upstream CPython 3.* development). I wrote a detailed summary on wiki: https://wiki.documentfoundation.org/Development/Python_Unit_Tests That: su -c debuginfo-install python3-3.3.0-1.fc18.x86_64 can probably be replaced with just: su -c debuginfo-install python3 since debuginfo-install has the smarts to pick the debuginfo package with the correct NVR (you *have* to have the debuginfo package for exactly the build of python3 that you're using, otherwise the debug information will be out of sync with the machine code, and gdb will understandably get too confused to give useful information). FWIW there are some more notes on how I made the debugging just work on Fedora here: http://fedoraproject.org/wiki/Features/EasierPythonDebugging if you're looking to do the same for your distro. Hope this is helpful Dave ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: claims of python unit test un-debugability considered somewhat exaggerated
On Wed, 2013-04-10 at 10:35 -0400, David Malcolm wrote: Works like a charm here on OpenSUSE 12.3 too, with system python3.3: [...snip...] Good to hear. FWIW there are some more notes on how I made the debugging just work on Fedora here: http://fedoraproject.org/wiki/Features/EasierPythonDebugging if you're looking to do the same for your distro. Hope this is helpful yes, indeed! I've found the missing package on OpenSUSE: python3-devel-debuginfo, which contains the libpython.py and updated the wiki correspondingly. The only question is now, how to skip the manual sourcing of libpython.py? If i understand it right, it happens automagically on Fedora? Here, only after source /usr/share/gdb/python/gdb/libpython.py (gdb) py-list and friends are available. Thanks David ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: claims of python unit test un-debugability considered somewhat exaggerated
David == David Ostrovsky d.ostrov...@gmx.de writes: David The only question is now, how to skip the manual sourcing of David libpython.py? If i understand it right, it happens automagically on David Fedora? Yes, Fedora installs /usr/lib/debug/usr/lib64/libpython2.7.so.1.0.debug-gdb.py (e.g.) as a hook file for gdb to load. And, it sets up gdb's trusted auto-load path to allow this. See: http://sourceware.org/gdb/current/onlinedocs/gdb/Python-Auto_002dloading.html#Python-Auto_002dloading Tom ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: claims of python unit test un-debugability considered somewhat exaggerated
Hi guys, On Mon, 2013-04-08 at 11:32 -0600, Tom Tromey wrote: CCing David Malcolm. Michael (gdb) py-bt I just wanted to mention here that Phil Muldoon is working on a frame filter patch series that is basically pretty printing for stack frames. With this in place you'll no longer need a special command -- with appropriate support from Python, you'll be able to see interpreted frames interleaved with the low-level C frames. Oh - nice ! :-) This series is nearing final review now and should appear in gdb 7.7, later this year. Excellent news indeed. I think we're planning to rewrite the existing py-bt code into frame filter form ourselves. So - in which case this significantly reduces the problems of using python for debugging; I assume that with py-bt - there are still issues with interleaving two tools for printing parts of backtraces when we call several times to and fro between C++ and python. Eventually we'd like to have more full support for mixed interpreter and C debugging. However this is a ways off. For me, clearly seeing the python line numbers is the key rather than the interpreter details - we treat python itself as working black-box - and the script itself as the problem ;-) So - re-examining my requirements: + debug-ability - when the test fails - and the best tests are written to fail regularly ;-) we need to be able -very-simply- to get a backtrace we can work with - without a ton of training, reading a dozen wiki pages, poking for obscure symbols, etc. Michael - as/when a python unit test fails - can we make the magic environment variables that are listed include some debugging instructions that include the py-bt detail etc. so that everything needed is in the failure message ? when we're in the automatic trace collection mode (I forget what env. var that is) do we dump the python pieces as well ? Also - can we distribute / include / install the magic that makes 'py-bt' work - not sure it works for me (on openSUSE - at least a facile start gdb, type py-bt fails in spades ;-) + that backtrace should not have big, opaque chunks that are either empty (cf. Java) or point to random / irrelevant pieces of C/C++ interpreter code - Python / StarBasic others. It should allow interactive inspection of variables up and down the stack. It seems that this is getting towards working on modern Linux systems. Do we get variable inspection sorted out there as well ? + reliability and performance: new unit tests should be small, fast, non-duplicative (ie. re-using existing code frameworks) I guess re-using the existing C++ test code / bootstrapping framework mostly avoids duplication here; and either way unit tests are (sadly) one of the more duplicative pieces of code we have. + ideally - the unit tests should run -in-the-same-process- which significantly helps with the above performance, debugging, reliability and more. And this is now fixed; so - David Michael - thanks for working on this - looks like a good solution with a brighter future :-) Thanks, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: claims of python unit test un-debugability considered somewhat exaggerated
Quoting Michael Meeks michael.me...@suse.com: Michael - as/when a python unit test fails - can we make the magic environment variables that are listed include some debugging instructions that include the py-bt detail etc. so that everything needed is in the failure message ? when we're in the automatic trace collection mode (I forget what env. var that is) do we dump the python pieces as well ? Also - can we distribute / include / install the magic that makes 'py-bt' work - not sure it works for me (on openSUSE - at least a facile start gdb, type py-bt fails in spades ;-) What we need here is a wiki page with detailed instructions how to set it up. Volunteers? ;-) David ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: claims of python unit test un-debugability considered somewhat exaggerated
On Tue, 2013-04-09 at 11:22 +0100, Michael Meeks wrote:
Hi guys,
On Mon, 2013-04-08 at 11:32 -0600, Tom Tromey wrote:
CCing David Malcolm.
Michael (gdb) py-bt
I just wanted to mention here that Phil Muldoon is working on a frame
filter patch series that is basically pretty printing for stack
frames. With this in place you'll no longer need a special command --
with appropriate support from Python, you'll be able to see interpreted
frames interleaved with the low-level C frames.
Oh - nice ! :-)
This series is nearing final review now and should appear in gdb 7.7,
later this year.
Excellent news indeed.
I think we're planning to rewrite the existing py-bt code into frame
filter form ourselves.
So - in which case this significantly reduces the problems of using
python for debugging; I assume that with py-bt - there are still issues
with interleaving two tools for printing parts of backtraces when we
call several times to and fro between C++ and python.
Eventually we'd like to have more full support for mixed interpreter
and C debugging. However this is a ways off.
For me, clearly seeing the python line numbers is the key rather than
the interpreter details - we treat python itself as working black-box -
and the script itself as the problem ;-)
Aha. Sorry; I came into this discussion halfway though.
I wrote the Python gdb hooks for CPython itself (i.e. py-bt and
others). You can see documentation for them here:
http://docs.python.org/devguide/gdb.html#gdb-7-and-later
In particular:
(gdb) py-list
should give you python source code for the current python frame.
So - re-examining my requirements:
+ debug-ability - when the test fails - and the best tests are
written to fail regularly ;-) we need to be able -very-simply-
to get a backtrace we can work with - without a ton of
training, reading a dozen wiki pages, poking for obscure
symbols, etc.
Michael - as/when a python unit test fails - can we make the magic
environment variables that are listed include some debugging
instructions that include the py-bt detail etc. so that everything
needed is in the failure message ? when we're in the automatic trace
collection mode (I forget what env. var that is) do we dump the python
pieces as well ? Also - can we distribute / include / install the magic
that makes 'py-bt' work - not sure it works for me (on openSUSE - at
least a facile start gdb, type py-bt fails in spades ;-)
On Fedora we package the python-gdb.py code so it appears in the
python-debuginfo rpm and is in the correct path so that it gets
autoloaded by gdb when libpython2.7.so is debugged.
Specifically (quoting Fedora's python3.spec):
# We install a collection of hooks for gdb that make it easier to debug
# executables linked against libpython3* (such as /usr/bin/python3 itself)
#
# These hooks are implemented in Python itself (though they are for the
version
# of python that gdb is linked with, in this case Python 2.7)
#
# gdb-archer looks for them in the same path as the ELF file, with a -gdb.py
suffix.
# We put them in the debuginfo package by installing them to e.g.:
# /usr/lib/debug/usr/lib/libpython3.2.so.1.0.debug-gdb.py
#
# See https://fedoraproject.org/wiki/Features/EasierPythonDebugging for more
# information
#
# Copy up the gdb hooks into place; the python file will be autoloaded by gdb
# when visiting libpython.so, provided that the python file is installed to
the
# same path as the library (or its .debug file) plus a -gdb.py suffix, e.g:
# /usr/lib/debug/usr/lib64/libpython3.2.so.1.0.debug-gdb.py
# (note that the debug path is /usr/lib/debug for both 32/64 bit)
#
# Initially I tried:
# /usr/lib/libpython3.1.so.1.0-gdb.py
# but doing so generated noise when ldconfig was rerun (rhbz:562980)
#
%if 0%{?with_gdb_hooks}
DirHoldingGdbPy=%{_prefix}/lib/debug/%{_libdir}
PathOfGdbPy=$DirHoldingGdbPy/$PyInstSoName.debug-gdb.py
mkdir -p %{buildroot}$DirHoldingGdbPy
cp Tools/gdb/libpython.py %{buildroot}$PathOfGdbPy
%endif # with_gdb_hooks
+ that backtrace should not have big, opaque chunks that
are either empty (cf. Java) or point to random / irrelevant
pieces of C/C++ interpreter code - Python / StarBasic
others. It should allow interactive inspection of variables
up and down the stack.
It seems that this is getting towards working on modern Linux systems.
Do we get variable inspection sorted out there as well ?
py-locals
py-print
+ reliability and performance: new unit tests should be small,
fast, non-duplicative (ie. re-using existing code
frameworks)
I guess re-using the existing C++ test code / bootstrapping framework
mostly avoids duplication here; and either way unit tests are (sadly)
one of the more duplicative pieces
Re: claims of python unit test un-debugability considered somewhat exaggerated
On Tue, 2013-04-09 at 11:26 -0400, David Malcolm wrote: On Tue, 2013-04-09 at 11:22 +0100, Michael Meeks wrote: Hi guys, On Mon, 2013-04-08 at 11:32 -0600, Tom Tromey wrote: CCing David Malcolm. Michael (gdb) py-bt I just wanted to mention here that Phil Muldoon is working on a frame filter patch series that is basically pretty printing for stack frames. With this in place you'll no longer need a special command -- with appropriate support from Python, you'll be able to see interpreted frames interleaved with the low-level C frames. Oh - nice ! :-) This series is nearing final review now and should appear in gdb 7.7, later this year. Excellent news indeed. I think we're planning to rewrite the existing py-bt code into frame filter form ourselves. So - in which case this significantly reduces the problems of using python for debugging; I assume that with py-bt - there are still issues with interleaving two tools for printing parts of backtraces when we call several times to and fro between C++ and python. Eventually we'd like to have more full support for mixed interpreter and C debugging. However this is a ways off. For me, clearly seeing the python line numbers is the key rather than the interpreter details - we treat python itself as working black-box - and the script itself as the problem ;-) Aha. Sorry; I came into this discussion halfway though. I wrote the Python gdb hooks for CPython itself (i.e. py-bt and others). You can see documentation for them here: http://docs.python.org/devguide/gdb.html#gdb-7-and-later In particular: (gdb) py-list should give you python source code for the current python frame. Works like a charm here on OpenSUSE 12.3 too, with system python3.3: (gdb) py-list 32) 33 34# property 'Value' is read only? 35@unittest.expectedFailure 36def test_get_expression_veto_read_only(self): 37os.kill(os.getpid(), signal.SIGUSR1) and (gdb) py-bt Traceback (most recent call first): File ./qa/unoapi/python/get_expression.py, line 37, in test_get_expression_veto_read_only os.kill(os.getpid(), signal.SIGUSR1) File /usr/lib64/python3.3/unittest/case.py, line 96, in wrapper func(*args, **kwargs) I must be missing something, but i didn't find a standard way how to install Tools/gdb/libpython.py from cpython, so i just cloned the upstream python, with hg clone http://hg.python.org/cpython and borrowed that lib from there (sourcing it manually on gdb): cpython/Tools/gdb/libpython.py I wrote a detailed summary on wiki: https://wiki.documentfoundation.org/Development/Python_Unit_Tests Enjoy the first backtrace from in-process python unit test ;-) David ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: claims of python unit test un-debugability considered somewhat exaggerated
On 2013-04-05 23:44, Michael Stahl wrote: 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. I consider this acceptable. So you can consider my objection to python unit tests withdrawn :-) Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: claims of python unit test un-debugability considered somewhat exaggerated
Michael == Michael Stahl mst...@redhat.com writes: CCing David Malcolm. Michael (gdb) py-bt I just wanted to mention here that Phil Muldoon is working on a frame filter patch series that is basically pretty printing for stack frames. With this in place you'll no longer need a special command -- with appropriate support from Python, you'll be able to see interpreted frames interleaved with the low-level C frames. This series is nearing final review now and should appear in gdb 7.7, later this year. I think we're planning to rewrite the existing py-bt code into frame filter form ourselves. Michael unfortunately one thing that i haven't found how to do is setting a Michael breakpoint in the python code from gdb... the best i've found is a lame Michael workaround of inserting a statement into the python code to send Michael yourself a signal, which is, well, a lame workaround: os.kill(os.getpid(), signal.SIGUSR1) Michael i wonder if it would be possible to easily add something to gdb to make Michael the python debugging a bit more seamless? Eventually we'd like to have more full support for mixed interpreter and C debugging. However this is a ways off. Meanwhile, you can do it, if you know some details about the interpreter implementation. It is just a question of setting a breakpoint at the right spot in the C code, with the right condition so that it only fires for your particular bit of code. Maybe David can say how. Perhaps the function__entry SDT probe point is apropos. Tom ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: claims of python unit test un-debugability considered somewhat exaggerated
On Mon, 2013-04-08 at 11:32 -0600, Tom Tromey wrote: Michael == Michael Stahl mst...@redhat.com writes: CCing David Malcolm. Michael (gdb) py-bt I just wanted to mention here that Phil Muldoon is working on a frame filter patch series that is basically pretty printing for stack frames. With this in place you'll no longer need a special command -- with appropriate support from Python, you'll be able to see interpreted frames interleaved with the low-level C frames. This series is nearing final review now and should appear in gdb 7.7, later this year. I think we're planning to rewrite the existing py-bt code into frame filter form ourselves. Michael unfortunately one thing that i haven't found how to do is setting a Michael breakpoint in the python code from gdb... the best i've found is a lame Michael workaround of inserting a statement into the python code to send Michael yourself a signal, which is, well, a lame workaround: os.kill(os.getpid(), signal.SIGUSR1) Michael i wonder if it would be possible to easily add something to gdb to make Michael the python debugging a bit more seamless? Eventually we'd like to have more full support for mixed interpreter and C debugging. However this is a ways off. Meanwhile, you can do it, if you know some details about the interpreter implementation. It is just a question of setting a breakpoint at the right spot in the C code, with the right condition so that it only fires for your particular bit of code. Maybe David can say how. Perhaps the function__entry SDT probe point is apropos. FWIW I have a (stalled) upstream CPython patch that adds a sys._breakpoint() hook here: http://bugs.python.org/issue9635 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
claims of python unit test un-debugability considered somewhat exaggerated
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
