[Ubuntu Wiki] Update of "DebuggerTalk" by rocky-bernstein

Tue May 15 08:45:41 UTC 2012

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification.

The "DebuggerTalk" page has been changed by rocky-bernstein:
http://wiki.ubuntu.com/DebuggerTalk?action=diff&rev1=28&rev2=29

Comment:
Revice for more recent activity

  
  In the practical arena, I could show how to use to debug an GNU automake project. There could be a theoretical area such as how to structure writing a debugger. (The ones for Ruby and Python are interesting here.)
  
- In the past people have asked me in the past, ''"what's the fascination with the debugger thing?"'' Or another favorite remark from a contractor is "''I never use a debugger, I just '''write''' code''". 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. 
+ In the past people have asked me in the past, ''"what's the fascination with the debugger thing?"'' Or another favorite remark from a contractor is "''I never use a debugger, I just '''write''' code''". 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 gdb? ===
+ === Why model debuggers off of gdb? ===
  
- Because it is 
+ 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
@@ -29, +29 @@

  
  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. 
+ 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 ===
  
@@ -37, +37 @@

   * 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.
+ 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: 
+ 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.
@@ -49, +49 @@

  
  === Work since the talk ===
  
- In 2008, I did something in between a port and a rewrite of this to support `ksh` and `zsh`. 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]].
+ 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. 
+ 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]]. Lessons learned in forking a project 
+ 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
@@ -71, +71 @@

   * run again with `remake -x`
   * if above doesn't work narrow target and run with `remake -X` ''target''
  
- Show: 
+ Show:
  
   * make basic debugging: `make -d basic`
   * make tracing: `remake -x`
@@ -79, +79 @@

   * 'step' and 'next'
   * showing dependencies and `write` command
   * Debugging a automake-generated Makefile.
-  
+ 
  
  === Future ===
  
@@ -91, +91 @@

  
  === 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. 
+ 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]]? 
+ 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. 
+ 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.
  
@@ -106, +106 @@

  
  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. 
+ 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:
  
@@ -114, +114 @@

    * 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).
+ 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. 
+ `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.''
  
@@ -132, +134 @@

   * 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?
+  * Complete rewrite for Ruby 1.9? ''This code is avaliable at https://github.com/rocky/rb-trepanning''
  ----
  CategoryDebugging
  

