DebuggerTalk_it

Introduzione

Praticamente affronteremo una discussione sui debugger che ho scritto o sui quali ho lavorato GNU bash, GNU make, Python,e Ruby. Gli argomenti affrontati andranno dallo storico al pratico.

Nell'arena pratica, 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. (Quelli per Ruby e Python sono interessanti qui).

In passato, qualcuno mi chiesto "cosa c'è di affascinante in un debugger?" Oppure un'osservazione fatta da un imprenditore fù "Non ho mai usato un debugger, io a malapena scrivo codice". In veste di amministratore di sistema, chiunque è sempre a confronto con una moltitudine di codice che non ha scritto. Si potrebbe sospettare che il codice non sia stato scritto perfettamente, e che sicuramente non ci sia molta documentazione o commenti nel codice. Nel caso si abbia un problema da risolvere, qui entra in gioco il debugger.

Ho anche sentito dire che voi non avete bisogno di un debugger perchè state usando una shell Bash, Python o Ruby ed avete appena iniziato a scrivere le dichiarazioni. Io ho bisogno di un oggetto foo dalla classe Foo e quindi devo agganciare la bar oggetto dalla classe Bar che significa importare o richiedere il modulo baz in foo prima che io possa chiamare ciò fubar che è ciò che mi serve. Con un debugger si lavora sul codice ed in maniera estesa. Quindi a grandi linee, la maggior parte dei necessari setup sono stati fatti per voi, con il proposito che un buon debugger non è per nulla diverso da una shell, semplicemente il contesto è già stato preimpostato. Vedremo questo in seguito nel debugger Phyton.

Perchè creare debugger diversi da gdb?

Tutto sommato gdb è:

  • piuttosto completo --- indica come espandere debugger inferiori (es. pdb e Ruby debug). Per esempio, considerare il signal handling.

  • ben noto --- il suo know-how migliora l'apprendimento degli altri. Aiuta anche nell'apprendimento di programmi.

  • è pronto --- perchè inventare un'altra interfaccia? Essendo GPL trae vantaggio dal manuale gdb, con citazioni

Problemi nello scrivere o utilizzare un debugger

  • Velocità --- i debugger possono rallentare i programmi
  • Confrontando la realtà virtualizzata con la realtà; induce a....

  • Heisenbugs (e come è influenzato dalla velocità)

GNU bash

Cenni storici

La storia sordida della trappola DEBUG. Originariamente come gli altri segnali, avviene dopo un'istruzione. Ma per poterne eseguire il debugging bisogna fermarsi prima. Pensate a "rm -fr /" e a quando vorreste saperlo. Ci sono voluti due anni per avere il cambiamento in bash da quando ho postato il suggerimento (e non ne ho mai avuto notizia). Il supporto al debug avviene in maniera molto lenta. Circa 4 anni fra quei rilasci.

Così mi decisi per il fork al codice bash ed aggiunsi il supporto di debug con storia cronologica. Questo codice è stato incorporato in bash 3.0. ringraziamenti a Masatake YAMATO.

Esempio pratico

  • L'opzione PS4

  • Utilizzo per il debug di script start/stop in SYSV.

  • L'opzione debugger set_trace? Nota: set_trace è deprecato in favore debugger

Nota: se si sta eseguendo il debugging di script configure, vorreste avere compreso il readarray. Ciò è stato incorporato in bash 4.0 e non è più necessario in quella e successive versioni.

A questo punto abbiamo visto tre paradigmi di debugging che verranno fuori di nuovo negli altri debugger:

  • line tracing
  • chiamata dal debugger all'outset
  • chiamare il debugger (in qualche modo) dall'interno del programm.

Vi è un'altra tecnica leggermente più difficile da usare in bash ma comunque più efficace

  • post-mortem debugging.

Lavorare mentre si parla

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) video which is really intended to be the first part of a more extended example.

Historical stuff

It's 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. Wink ;-)

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, 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 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 roots at the bottom?

Practical example

I have a short 15-minute 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 ipython was recently done. Release 1.21 added a number of usability conveniences like better command completion, and 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 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 Calling the debugger from inside your Ruby Program and The Debugger Module for even more detail.

Future Work

CategoryDebugging

DebuggerTalk_it (last edited 2012-06-06 14:46:49 by dynamic-adsl-78-14-228-143)