GRASS Debugging: Difference between revisions
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 | ==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.