GRASS Debugging: Difference between revisions

From GRASS-Wiki
Jump to navigation Jump to search
(url added)
Line 21: Line 21:
* for example: strace v.in.ogr out=bla dsn="PG:dbname=postgis user=me" olayer=postgislayer
* for example: strace v.in.ogr out=bla dsn="PG:dbname=postgis user=me" olayer=postgislayer


==Skimming !ChangLog for changes==
==Skimming ChangLog for changes==
* use the tool cvs2cl.pl for generating a local changelog-file
* use the tool [http://www.red-bean.com/cvs2cl/ cvs2cl.pl] for generating a local changelog-file


==Using DDD (gdb graphical frontend)==
==Using DDD (gdb graphical frontend)==

Revision as of 10:27, 28 May 2006

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 v.in.ogr`
  • 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 v.in.ogr out=bla dsn="PG:dbname=postgis user=me" olayer=postgislayer

Skimming ChangLog for changes

  • use the tool cvs2cl.pl 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 v.in.ogr`

http://mpa.itc.it/markus/grass61/debugging/crash_1_small.jpg

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

http://mpa.itc.it/markus/grass61/debugging/ddd_1_small.jpg

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

http://mpa.itc.it/markus/grass61/debugging/ddd_2_going_up_small.jpg

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

http://mpa.itc.it/markus/grass61/debugging/ddd_3_breakpoint_small.jpg

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

http://mpa.itc.it/markus/grass61/debugging/ddd_4_displ_vars_small.jpg

  • 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.