[Ubuntu Wiki] Update of "DebuggerTalk_it" by fabiomarconi
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification.
The "DebuggerTalk_it" page has been changed by fabiomarconi:
http://wiki.ubuntu.com/DebuggerTalk_it
Comment:
Italian translation started
New page:
||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents>>||
== Introduzione ==
Praticamente affronteremo una discussione sui debugger che ho scrittto o sui quali ho lavorato
[[http://bashdb.sf.net|GNU bash]], [[http://bashdb.sf.net/remake|GNU make]],
[[http://bashdb.sf.net/pydb|Python]],e [[http://rubyforge.org/projects/ruby-debug/|Ruby]].
Gli agomenti affrontati andranno dallo storico al pratico.
Nell'arena pratica, io posso mostrare come utilizzare per il debug un progetto GNU automake. Ad esempio,
ci potrebbe essere un campo teorico su come strutturare la scrittura di un debugger. (There could be a
theoretical area such as how to structure writing a debugger. (Quelli per ruby e Python sono interessanti qui).
In passato, qualcuno mi chieset ''"cosa c'è di affascinante in un debugger?"'' Oppure un'osservazione
fatta da un imprenditore fù "''Non ho mai usato un debugger, io '''scrivo''' codice''". As a systems
administrator one is often confronted with lots of code that you didn't write. You suspect the code might
not even be written all that well, but you are more sure that there isn't much in the way of documentation or
comments in the code. And you've got a problem to solve. Here is where a debugger comes into play.
I've also heard the observation that you don't need a debugger because you go into a Bash, Python or Ruby
shell and just start typing statements in the language. Again if you have a high-level idea of what's going
on, that's great. However the hardest part here is getting the context correct. I need a `foo` object from
class `Foo` and then need to hook the `bar` object from class `Bar` which means importing or requiring
module `baz` into `foo` before I can call this method `fubar` that is of interest to me. With a debugger you
work on code that purports to work and largely does. So for the most part, most of the necessary setup has
been done for you. In a sense a ''good'' debugger is really not all that different than a shell, it's just
that the context has already been set up for you. We'll see that in the Python debugger later.
=== Why model debuggers off of gdb? ===
Because it is
* fairly complete --- suggests how to expand lesser debuggers (e.g. `pdb` and Ruby's `debug`). For
example, consider signal handling.
* well known --- learning one helps learn another. It helps ''programs'' learn too!
* it's there --- why invent a new interface? Because is GPL can cull from gdb manual, with citation
=== Issues in Writing or Using a Debugger ===
* Speed --- debuggers can slow down your program
* Matching virtual reality to reality; which naturally leads to...
* [[http://en.wikipedia.org/wiki/Heisenbug#Heisenbugs|Heisenbugs]] (and speed contributes to
this as well)
== GNU bash ==
=== Historical stuff ===
The sordid history of `trap DEBUG`. Originally like other signals, it came ''after'' a statement. But for
debugging you need to stop before. Think "`rm -fr /`" and when you'd like to know about it. It took about 2
years after I posted a suggestion for the change to get into bash (and I never got an acknowledgment about
this). Debug support was going way too slowly. About 4 years between those releases.
So I forked the bash code to add debug support and timestamped history. This code was incorporated into bash
3.0. Many thanks to Masatake YAMATO.
=== Practical example ===
* [[http://bashdb.sourceforge.net/bashdb.html#PS4|PS4]] trick
* Using to debug SYSV start/stop scripts.
* debugger `set_trace` trick? ''Note: `set_trace` is depricated in favor of `debugger`''
Note: if you are going to debug `configure` scripts, you want the `readarray` builtin. ''This has since
been encorporated into bash 4.0 and is not needed in that and later versions''
At this point we should have seen three paradigms of debugging that will come up over again in the other debuggers:
* line tracing
* invoking from the debugger at the outset
* calling the debugger (somehow) from inside the program.
There's one more technique that's a little hard to use in bash but is more prevalent elsewhere
* post-mortem debugging.
=== Work since the talk ===
In 2008, I did something in between a port and a rewrite of this to support `ksh` and `zsh` and colorized
output via *pygments*. As before, changes were needed in the shells themselves to support more accurate
location reporting and to be able to do more program introspection. Much to my delight, these
enhancements were done quickly and with little involvement on my part. But this means you do need a recent
release of these shells. The debugger code is maintained on `github`. See
[[http://github.com/rocky/zshdb]] and [[http://github.com/rocky/kshdb]].
== GNU make ==
I have a short (13 minute)
[[http://showmedo.com/videos/video?name=linuxBernsteinMakeDebug1&fromSeriesID=40|video]]
which is really intended to be the first part of a more extended example.
=== Historical stuff ===
It's [[http://freshmeat.net/articles/view/889/#comment-31152|deja vu all over again]].
What needed to be done (same as in bash):
* better position location reporting
* keep target stack (like a call stack)
* get tracing working first and then add a interactive command loop
=== Practical example ===
Method I use to solve a Makefile problem:
* use normal make (until failure)
* run again with `remake -x`
* if above doesn't work narrow target and run with `remake -X` ''target''
Show:
* make basic debugging: `make -d basic`
* make tracing: `remake -x`
* post-mortem debugging
* 'step' and 'next'
* showing dependencies and `write` command
* Debugging a automake-generated Makefile.
=== Future ===
What's there now is good enough for me. If it's not for others, I encourage involvement. 
The original version was somewhere between 3.80 and 3.81. In 2008, a fresh conversion was done for 3.81 Some
of this could possibly get folded back into GNU Make but it may mean a ''regression'' in coding style. (Dan
Fabulich once expressed interest in doing this.)
== Python ==
=== Historical stuff ===
There are two gdb-like debuggers. The stock python debugger,
[[http://docs.python.org/lib/module-pdb.html|pdb]], and one that grew from that, called `pydb`.
The name `pydb` is because at about the time `pdb` was developed Richard Wolff was working in parallel on a
debugger to be embedded on [[http://www.gnu.org/software/ddd|ddd]]. He has since retired and with his
blessing I've taken over the name and have been sort of maintaining the ddd embedding as well.
Stack frame display dilemma: do Python programmers draw their trees with the
[[http://groups.google.com/group/comp.lang.python/browse_thread/thread/90cbcd03f37294a1/caa85f727c28353a|roots
at the bottom]]?
=== Practical example ===
I have a short 15-minute
[[http://showmedo.com/videos/video?name=pythonBernsteinPydbIntro&fromSeriesID=28|video]]
showing off some non-pdb things.
Example: how `ipython` handles `help` --- signal handling (initially added by Matt Fleming as part of a
Google 2006 Summer-of-code project. Possibly some of the thread debugging features.
=== Recent and Future work ===
Integration into [[http://ipython.scipy.org/moin/|ipython]] was recently done. Release 1.21 added a
number of usability conveniences like better command completion, and
[[http://docs.python.org/lib/module-pydoc.html|pydoc]] help.
Remote debugging. This is needed to hook into many IDEs like Eric, IDLE, winpdb (and therefore SPE), and
Eclipse. The bad news though is that each IDE has defined it's own protocol for working remotely.
In late 2008, I started working on a complete rewrite. Some features planned:
* remote debugging
* much more modular (and more along the lines of `ruby-debug`)
* distribution via egg package(s)
''Code is available at http://code.google.com/p/pydbgr/''
== Ruby ==
There are in fact two ruby debuggers. `debug` which comes with the base Ruby install and
[[http://rubyforge.org/projects/ruby-debug/|ruby-debug]] by Kent Sibilev. Both are roughly gdb
like. Kent's debugger is I think is coded the cleanest of any debugger I've seen (although it does have some
warts). Each command is its own class. By way of comparison,
in the stock Python debugger a command module is used. Commands are methods in this (sub)class whose names
start with the "do_". This is a pattern akin to one used in unit testing where tests start with "test_". But
having a class per command is cooler. It means that commands can have ''properties''. One property in
`ruby-debug` is whether you can run this command if the program has crashed. (The `help` command you can
run, but the `step` command you can't).
=== Practical Example ===
`require 'debug'` trick? Stopping in a Rails unit test.
''Note: since this talk, `ruby-debug` has become the de-facto debugger that is used in Ruby, JRuby,
Ruby/Rails, merb and other frameworks. The successor to the `require 'debug'` trick is now `require
'ruby-debug/debugger'` or some variation of that. See
[[http://bashdb.sourceforge.net/ruby-debug.html#SEC18|Calling the debugger from inside your
Ruby Program]] and [[http://bashdb.sourceforge.net/ruby-debug.html#SEC72|The Debugger Module]]
for even more detail.''
=== Future Work ===
* Aptana and Eclipse plugin (Done sometime in 2007 via ruby-debug-base.)
* Documentation (largely done in 2007; see [[http://bashdb.sf.net/ruby-debug.html]] and [[http://bashdb.sf.net/ruby-debug/index.html]])
* Regression tests. (Largely done in 2007.)
* More closely like gdb (Much progress here too; caused some incompatible changes.)
* Complete rewrite for Ruby 1.9? ''This code is avaliable at https://github.com/rocky/rb-trepanning''
----
CategoryDebugging
--
--
Ubuntu-bugsquad mailing list
Ubuntu-bugsquad <at> lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad
RSS Feed