GRASS Debugging

From GRASS-Wiki
Revision as of 11:58, 19 May 2006 by Dassau (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

The following hints assume to work on a working-copy of the GRASS CVS dierctory.

Additionally it is good to have set the debbugging symbols during compile-time. Do not strip the libraries or use optimization in the compile. see INSTALL and doc/debugging.txt in the source code for more information.

Setting Environment-variables (numbers: 1-5)

  • g.gisenv set="DEBUG=1"
  • A higher debug level means you see more messages.
  • These messages are always present regardless of compiler settings.

Using GDB

  • running a programm inside GDB works (installation of GDB required :-), (on debian: apt-get install gdb)
  • gdb `which`
  • run "out=bla dsn="PG:dbname=postgis user=me" olayer=postgislayer"
  • when it crashes, just type bt full for a backtrace
  • type "l" to list where in the source code it got to
  • type frame 2 to switch to the second level function (see the backtrace), there you can again type "l" to see where it got up to.

Using strace

  • running the command through strace could give you another hint what is going wrong somewhere.
  • for example: strace out=bla dsn="PG:dbname=postgis user=me" olayer=postgislayer

Skimming !ChangLog for changes

  • use the tool for generating a local changelog-file

Using DDD (gdb graphical frontend)

  • running a programm inside ddd works (installation of ddd and gdb required :-), (on debian: apt-get install gdb ddd)
  • ddd `which`

  • Run (from main menu PROGRAM): "out=bla dsn="PG:dbname=postgis user=me" olayer=postgislayer"

  • run with parameters
  • when it crashes, use the UP menu item to trace back

  • reach the line where it crashed
  • set a breakpoint, then run again to stop before the crash

  • right mouse button on variables permits to display them etc.


  • figure out why it crashed there. This requires PATIENCE. But you will nearly save the world if you identify the problem :-)

Using kdbg (gdb graphical frontend)

  • kdbg is not unlike DDD, but it's a KDE application.
  • Use is similar to ddd.
  • Start with (within GRASS):

kdbg `which g.module`

  • Fill in command line arguments with menu item Execution->Arguments.
  • Open the View->Locals window.
  • Click the Run icon (or Execution->Run) and see where it breaks.
  • Set pause-points by clicking a red stop-sign to the left of the "+" on a line of the source code. From there you can step through instructions.
  • Explore the values of variables in the locals window.