Difference between revisions of "GRASS Debugging"

From GRASS-Wiki
Jump to: navigation, search
(+ Using LD_DEBUG)
m (various URLs updated)
(8 intermediate revisions by the same user not shown)
Line 1: Line 1:
The following hints assume to work on a working-copy of the {{twiki|DownloadSource#SubversionGRASSmainsourcecoderepository|GRASS SVN}} directory.
+
The following hints assume to work on a working-copy of the {{twiki|DownloadSource#SubversionGRASSmainsourcecoderepository|GRASS GIS source code} directory.
  
 
Additionally it is good to have set the debugging symbols during compile-time. Do not strip the libraries or use optimization in the compile. see {{src|INSTALL}} and {{src|doc/debugging.txt}} in the source code for more information.
 
Additionally it is good to have set the debugging symbols during compile-time. Do not strip the libraries or use optimization in the compile. see {{src|INSTALL}} and {{src|doc/debugging.txt}} in the source code for more information.
Line 5: Line 5:
 
== Reporting bugs ==
 
== Reporting bugs ==
  
* Bugs should be reported in the GRASS [http://grass.osgeo.org/bugtracking/index.php bug and wish tracker].
+
* Bugs should be reported in the GRASS GIS [https://github.com/OSGeo/grass/issues bug and wish tracker].
  
 
* Please use [[GRASS_messages_translation#How_to_change_the_language|untranslated messages]] in your bug reports. The following command will disable the use of translated messages:
 
* Please use [[GRASS_messages_translation#How_to_change_the_language|untranslated messages]] in your bug reports. The following command will disable the use of translated messages:
Line 38: Line 38:
 
All GRASS modules send out a return code of "0" if they exit successfully and "1" if they have exited with an error. This is typically accompanied by an "ERROR: " message.
 
All GRASS modules send out a return code of "0" if they exit successfully and "1" if they have exited with an error. This is typically accompanied by an "ERROR: " message.
  
On UNIX (Linux, Macintosh OSX, and [[Cygwin]]) directly after a command line module ends you can type "<tt>echo $?</tt>" and it will tell you the exit code. In a MS-Windows DOS box the equivalent command is "<tt>echo %errorlevel%</tt>".
+
On UNIX (Linux, Mac OS, and [[Cygwin]]) directly after a command line module ends you can type "<tt>echo $?</tt>" and it will tell you the exit code. In a MS-Windows DOS box the equivalent command is "<tt>echo %errorlevel%</tt>".
  
 
Note that some modules (like {{cmd|g.findfile}}) exit with a status of 1 if it (for example) could not find a file, which may be exactly the test the module was run to perform. In that way the return code can be used in script logic.  Thus the exit code only reports EXIT_SUCCESS or EXIT_FAILURE, but a failure can happen for any number of reasons, expected or unexpected, and is not a reason to panic in and of itself.
 
Note that some modules (like {{cmd|g.findfile}}) exit with a status of 1 if it (for example) could not find a file, which may be exactly the test the module was run to perform. In that way the return code can be used in script logic.  Thus the exit code only reports EXIT_SUCCESS or EXIT_FAILURE, but a failure can happen for any number of reasons, expected or unexpected, and is not a reason to panic in and of itself.
Line 53: Line 53:
 
== Using GDB ==
 
== Using GDB ==
  
The [http://sourceware.org/gdb/ GNU Debugger] may be used to diagnose '''<tt>Segmentation Faults</tt>''' and other weirdness.
+
The [https://www.gnu.org/software/gdb/ GNU Debugger] may be used to diagnose '''<tt>Segmentation Faults</tt>''' and other weirdness.
  
 
=== Compile Time Setup ===
 
=== Compile Time Setup ===
  
To add debugging information into the built binary, add ''-g'' to the CFLAGS arguments.
+
To add debugging information into the built binary, first run
 +
make distclean
 +
 
 +
Then configure the source code with ''-g'' being added to the CFLAGS arguments:
  
 
  CFLAGS="-ggdb -Wall -Werror-implicit-function-declaration" ./configure ...
 
  CFLAGS="-ggdb -Wall -Werror-implicit-function-declaration" ./configure ...
Line 63: Line 66:
 
Do '''not''' use ''-O'' for optimization and do '''not''' strip the binaries with LDFLAGS="-s".
 
Do '''not''' use ''-O'' for optimization and do '''not''' strip the binaries with LDFLAGS="-s".
  
==== Debug symbols for Debian packages ====
+
Eventually compile the source code and start the GRSS GIS session for debugging (see below).
 
 
If you are using the Debian package of GRASS the binaries will be stripped at the factory and gcc's -g flag will not have been used in the build.
 
You can however drop in packages from http://debug.debian.net which will be slightly larger and run slightly slower, but will include the debug symbols which make gdb output understandable to us humans.
 
  
 
=== Using gdb on command line ===
 
=== Using gdb on command line ===
  
* Running a program inside [http://en.wikipedia.org/wiki/Gdb GDB] works (installation of GDB required :-)
+
* Running a program inside [https://en.wikipedia.org/wiki/Gdb GDB] works (installation of GDB required :-)
: (e.g. on [http://www.debian.org Debian GNU/Linux]: apt-get install gdb)
+
: (e.g. on [https://www.debian.org Debian GNU/Linux]: apt-get install gdb)
  
 
* Use the exact module name on the command line (at the GRASS prompt) without arguments. Put any command line arguments on the <tt>(gdb)</tt> command line after the word ''run''.
 
* Use the exact module name on the command line (at the GRASS prompt) without arguments. Put any command line arguments on the <tt>(gdb)</tt> command line after the word ''run''.
Line 103: Line 103:
 
It is important to note that you must analyze the ''core'' file against the exact version of the executable you were running at the time, and that if you send the ''core'' file to someone else they will be able to see the data you had loaded in the program at the time (if you are a consultant, you client might not like that).
 
It is important to note that you must analyze the ''core'' file against the exact version of the executable you were running at the time, and that if you send the ''core'' file to someone else they will be able to see the data you had loaded in the program at the time (if you are a consultant, you client might not like that).
  
 
+
<!-- Tcl/TK has been dropped years ago
 
=== Using gdb with a mixed C/TclTK application ===
 
=== Using gdb with a mixed C/TclTK application ===
  
Line 130: Line 130:
 
through the function (with "next"), printing out the values of any
 
through the function (with "next"), printing out the values of any
 
variables as they are assigned.
 
variables as they are assigned.
 +
-->
  
 
=== Using gdb within GNU Emacs ===
 
=== Using gdb within GNU Emacs ===
Line 137: Line 138:
 
:* 'M' is usually key 'Alt'
 
:* 'M' is usually key 'Alt'
  
* start [http://en.wikipedia.org/wiki/Emacs GNU Emacs] within GRASS session, e.g.
+
* start [https://en.wikipedia.org/wiki/Emacs GNU Emacs] within GRASS session, e.g.
  
 
  emacs general/manage/cmd/remove.c
 
  emacs general/manage/cmd/remove.c
Line 155: Line 156:
  
 
=== Using DDD (gdb graphical frontend) ===
 
=== Using DDD (gdb graphical frontend) ===
* debugging a program inside [http://en.wikipedia.org/wiki/Ddd DDD] is rather easy (installation of ddd and gdb required), (on Debian GNU/Linux: <tt>apt-get install gdb ddd</tt>; on Mandriva: <tt>urpmi ddd</tt>). Start debugger with GRASS command (e.g., {{cmd|v.in.ogr}}):
+
* debugging a program inside [https://en.wikipedia.org/wiki/Ddd DDD] is rather easy (installation of ddd and gdb required), (on Debian GNU/Linux: <tt>apt-get install gdb ddd</tt>; on Fedora: <tt>dnf install ddd</tt>). Start debugger with GRASS command (e.g., {{cmd|v.in.ogr}}):
  
 
  ddd v.in.ogr
 
  ddd v.in.ogr
Line 201: Line 202:
 
  GRASS> ldd `which v.in.ogr`
 
  GRASS> ldd `which v.in.ogr`
 
For a library:
 
For a library:
  $ ldd /usr/src/grass/grass-6.2.2/dist.i686-pc-linux-gnu/lib/libgrass_gis.so
+
  $ ldd /usr/src/grass/grass78/dist.x86_64-pc-linux-gnu/lib/libgrass_gis.so  
 
 
The output looks like this:
 
        libz.so.1 => /usr/lib/libz.so.1 (0x40077000)
 
        libgrass_datetime.so => not found
 
        libc.so.6 => /lib/libc.so.6 (0x4008a000)
 
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
 
  
In the above example <tt>libgrass_datetime.so</tt> is missing causing an <tt>Illegal Instruction</tt> error in ''libgis''. A common error occurs when there are more than one versions of a support library installed, and the GRASS build is using the wrong one. ''ldd'' is good for spotting this.
+
The output may look like this:
 +
linux-vdso.so.1 (0x00007ffe1cf03000)
 +
libgrass_datetime.7.8.so => /usr/src/grass/grass78/dist.x86_64-pc-linux-gnulib/libgrass_datetime.7.8.so (0x00007fae7a6cf000)
 +
libz.so.1 => /lib64/libz.so.1 (0x00007fae7a6b5000)
 +
libzstd.so.1 => /lib64/libzstd.so.1 (0x00007fae7a5df000)
 +
libm.so.6 => /lib64/libm.so.6 (0x00007fae7a499000)
 +
libc.so.6 => /lib64/libc.so.6 (0x00007fae7a2cf000)
 +
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fae7a2ad000)
 +
/lib64/ld-linux-x86-64.so.2 (0x00007fae7a769000)
  
* In <span style="border-bottom: 1px solid #000;">Cygwin</span> the "cygcheck" program is used inplace of ldd. See the [http://grass.osgeo.org/grass62/binary/mswindows/#trouble Cygwin troubleshooting page] for information on using that.
+
''ldd'' is good for spotting if the right libraries are used (in the correct path etc).
  
* On <span style="border-bottom: 1px solid #000;">Mac OSX</span> "otool -L `which v.in.ogr`" almost does the same job.
+
* On <span style="border-bottom: 1px solid #000;">Mac OS</span> "otool -L `which v.in.ogr`" almost does the same job.
  
* For <span style="border-bottom: 1px solid #000;">MS Windows</span> the [http://www.dependencywalker.com/ Dependency Walker] program (depends.exe) might help.
+
* For <span style="border-bottom: 1px solid #000;">MS Windows</span> the [https://www.dependencywalker.com/ Dependency Walker] program (depends.exe) might help.
  
 
=== Library search path ===
 
=== Library search path ===
Line 224: Line 227:
 
Alternatively you can add the library path to the $LD_LIBRARY_PATH environmental variable.
 
Alternatively you can add the library path to the $LD_LIBRARY_PATH environmental variable.
  
* [http://www.cprogramming.com/tutorial/shared-libraries-linux-gcc.html Read more about how shared libraries work on Linux]
+
* [https://www.cprogramming.com/tutorial/shared-libraries-linux-gcc.html Read more about how shared libraries work on Linux]
  
 
== Using nm and objdump ==
 
== Using nm and objdump ==
Line 260: Line 263:
 
== Using Valgrind ==
 
== Using Valgrind ==
  
* [http://valgrind.org Valgrind] is a tool to check for memory leaks and memory errors.
+
* [https://valgrind.org Valgrind] is a tool to check for memory leaks and memory errors.
  
 
;Examples
 
;Examples
Line 283: Line 286:
 
* Valgrind can create PostScript output charts. To convert PostScript to PNG:
 
* Valgrind can create PostScript output charts. To convert PostScript to PNG:
 
: ('pstoimg' is part of the latex2html Debian package)
 
: ('pstoimg' is part of the latex2html Debian package)
 +
 +
* If you get something like this (huge value for "still reachable"):
 +
<pre>
 +
> ==13217== LEAK SUMMARY:
 +
> ==13217==    definitely lost: 964 bytes in 39 blocks
 +
> ==13217==    indirectly lost: 72 bytes in 10 blocks
 +
> ==13217==      possibly lost: 79 bytes in 4 blocks
 +
> ==13217==    still reachable: 9,025,026,330 bytes in 188,201,312 blocks
 +
</pre>
 +
then please run valgrind again with <tt>--show-reachable=yes</tt> as you will want to find out where these 9,025,026,330 bytes (in this example) have been allocated.
 +
  
 
  pstoimg -aaliastext -flip r90 -out massif.550.png -scale 1.3 -crop a massif.550.ps
 
  pstoimg -aaliastext -flip r90 -out massif.550.png -scale 1.3 -crop a massif.550.ps
  
 
* '''Graphical user interfaces''':  
 
* '''Graphical user interfaces''':  
** http://kcachegrind.sourceforge.net/
+
** https://kcachegrind.github.io/html/Home.html
** https://projects.kde.org/projects/extragear/sdk/massif-visualizer
+
** https://invent.kde.org/sdk/massif-visualizer
** https://wiki.gnome.org/action/show/Apps/MassifG
+
** https://wiki.gnome.org/Attic/MassifG
  
 
== Using Electric Fence ==
 
== Using Electric Fence ==
  
* [http://perens.com/FreeSoftware/ Electric Fence] checks for bad memory writes, ie specific malloc() over-runs and under-runs.
+
* [https://en.wikipedia.org/wiki/Electric_Fence Electric Fence] checks for bad memory writes, ie specific malloc() over-runs and under-runs.
  
 
('''''Insert howto here''''')
 
('''''Insert howto here''''')
Line 308: Line 322:
 
=== Kcachegrind ===  
 
=== Kcachegrind ===  
  
[http://kcachegrind.sourceforge.net kcachegrind] is a visualization tool for [http://valgrind.org Valgrind]'s callgrind profiling tool (formerly known as the calltree skin). It is very simple to use. Install the GraphViz package as well.
+
[https://kcachegrind.github.io/html/Home.html kcachegrind] is a visualization tool for [https://valgrind.org Valgrind]'s callgrind profiling tool (formerly known as the calltree skin). It is very simple to use. Install the GraphViz package as well.
  
* The [http://valgrind.org/docs/manual/cl-manual.html callgrind chapter] in the Valgrind user manual
+
* The [https://valgrind.org/docs/manual/cl-manual.html callgrind chapter] in the Valgrind user manual
  
 
Example:
 
Example:
 
  # Spearfish dataset
 
  # Spearfish dataset
  g.region rast=elevation.dem
+
  g.region raster=elevation.dem
 
  v.random n=10000 out=rand10k
 
  v.random n=10000 out=rand10k
 
  v.db.addtable rand10k column="elev INT"
 
  v.db.addtable rand10k column="elev INT"
Line 328: Line 342:
 
=== gprof ===
 
=== gprof ===
  
* [http://www.cs.utah.edu/dept/old/texinfo/as/gprof_toc.html GNU gprof] user guide
+
* [https://sourceware.org/binutils/docs/gprof/ GNU gprof] user guide
 
* [http://linuxgazette.net/100/vinayak.html Profiling programs using gprof] - article from the Linux Gazzette, March 2004 (#100)
 
* [http://linuxgazette.net/100/vinayak.html Profiling programs using gprof] - article from the Linux Gazzette, March 2004 (#100)
  
Line 366: Line 380:
 
== Skimming the ChangeLog for changes ==
 
== Skimming the ChangeLog for changes ==
  
* use the tool {{src|tools/svn2cl.sh}} for generating a local changelog-file
+
* use the tool {{src|tools/gitlog2changelog.py}} for generating a local changelog-file, by simply running:
<!--
+
** make changelog
* use the tool [http://www.red-bean.com/cvs2cl/ cvs2cl.pl] for generating a local changelog-file
 
: (it can be found in the <tt>tools/</tt> directory in the GRASS 6 source code)
 
-->
 
  
 +
<!-- abandoned years ago
 
== Tcl/Tk debugging ==
 
== Tcl/Tk debugging ==
  
Line 394: Line 406:
 
** "Tcl quoting hell"  http://wiki.tcl.tk/1726
 
** "Tcl quoting hell"  http://wiki.tcl.tk/1726
 
** "1 minute intro to tcl"  http://www.pconline.com/~erc/tcl.htm
 
** "1 minute intro to tcl"  http://www.pconline.com/~erc/tcl.htm
 +
-->
  
 
== Shell script debugging ==
 
== Shell script debugging ==
Line 413: Line 426:
  
 
=== Python debugging with pdb ===
 
=== Python debugging with pdb ===
 +
 +
See also:
 +
* pdb Background: https://docs.python.org/3/library/pdb.html
 +
* pdb Tutorial: https://fedoramagazine.org/getting-started-python-debugger/
  
 
1. Edit the GRASS python script and add this line to the import section:
 
1. Edit the GRASS python script and add this line to the import section:
Line 427: Line 444:
 
r.unpack x60030_2000.green.histo2000_g.pack
 
r.unpack x60030_2000.green.histo2000_g.pack
 
<source lang="python">
 
<source lang="python">
GRASS 7.0.svn (patUTM32):~ > r.unpack x60030_2000.green.histo2000_g.pack
+
GRASS 7.8 (patUTM32):~ > r.unpack x60030_2000.green.histo2000_g.pack
> /home/neteler/software/grass70/dist.x86_64-unknown-linux-gnu/scripts/r.unpack(93)main()
+
> /home/neteler/software/grass78/dist.x86_64-unknown-linux-gnu/scripts/r.unpack(93)main()
 
-> diff_result_1 = diff_result_2 = None
 
-> diff_result_1 = diff_result_2 = None
 
</source>
 
</source>
  
3. Now you can either (s)tep through or (r)run the rest (c: continue, q: quit)
+
3. Now you can either (s)tep through or (n)ext or (r)run the rest (c: continue, q: quit)
 
<source lang="python">
 
<source lang="python">
 
(Pdb) s
 
(Pdb) s
 
</source>
 
</source>
 +
 +
While "s" will decend in functions, "n" will go to the next line. See the manual for [https://docs.python.org/2/library/pdb.html#debugger-commands Debugger Commands]
  
 
4. To print the content of variables:
 
4. To print the content of variables:
 
<source lang="python">
 
<source lang="python">
 
(Pdb) s
 
(Pdb) s
> /usr/lib64/python2.7/posixpath.py(73)join()
+
> /usr/lib64/python3.8/posixpath.py(73)join()
 
-> path = a
 
-> path = a
 
(Pdb) a
 
(Pdb) a
Line 450: Line 469:
 
Now will likely be able to better find the issues in your Python script.
 
Now will likely be able to better find the issues in your Python script.
  
See also: http://docs.python.org/library/pdb.html
+
See also: https://docs.python.org/3/library/pdb.html
  
 
=== wxPython GUI debugging ===
 
=== wxPython GUI debugging ===
 +
 +
'''A) Debug messages:'''
  
 
[[wxGUI]] prints debugging messages in five levels (1-5). To redirect these messages to the terminal, run
 
[[wxGUI]] prints debugging messages in five levels (1-5). To redirect these messages to the terminal, run
  
* in GRASS 6.4.2+
+
* in GRASS 7.x
  
 
  g.gisenv set=WX_DEBUG=1
 
  g.gisenv set=WX_DEBUG=1
  
* in GRASS 6.4.0, 6.4.1 (for bash)
+
'''B) Using a debugger:'''
  
  $ export GRASS_WX_DEBUG=1
+
For real debugging of wxgui.py ([https://github.com/OSGeo/grass/blob/master/general/g.gui/main.c source code]) with gdb or other tools, so you can use something like:
 +
 
 +
  cd grass/src
 +
python gui/wxpython/wxgui.py
 +
 
 +
or:
 +
 
 +
python $GISBASE/gui/wxpython/wxgui.py
 +
 
 +
Well, but that's just how to run the Python code directly.
  
 
=== Python debugging with gdb ===
 
=== Python debugging with gdb ===
  
See http://wiki.python.org/moin/DebuggingWithGdb
+
See https://wiki.python.org/moin/DebuggingWithGdb
  
 
===  Komodo dbgp.client.brk() ===
 
===  Komodo dbgp.client.brk() ===
Line 475: Line 505:
 
=== Profiling python scripts ===
 
=== Profiling python scripts ===
  
* See http://docs.python.org/library/profile.html
+
* See https://docs.python.org/library/profile.html
 +
 
 +
== PROJ debugging ==
  
== PROJ.4 debugging ==
+
See also: https://proj.org/usage/environmentvars.html?highlight=debugging
  
For unix with a bourne style shell use export:
+
For unix with a style shell use export:
 
  export PROJ_DEBUG=5
 
  export PROJ_DEBUG=5
 
  cs2cs ...
 
  cs2cs ...
 
  
  
 
[[Category:Development]]
 
[[Category:Development]]

Revision as of 12:37, 30 August 2020

The following hints assume to work on a working-copy of the {{twiki|DownloadSource#SubversionGRASSmainsourcecoderepository|GRASS GIS source code} directory.

Additionally it is good to have set the debugging 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.

Reporting bugs

  • Please use untranslated messages in your bug reports. The following command will disable the use of translated messages:
 export LC_ALL=C

Patches

  • For instructions on creating and applying patches the see Patches wiki page.

Setting GRASS-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.
  • A setting of "5" is the most verbose, "0" is no debug messages.

Common problems

  • Check that the region settings are not totally overwhelming for the raster engine. While there is no set upper limit, anything bigger than 20000x20000 is considered large, and anything an order of mangnitude bigger than that will most likely end with out of memory or large file problems, especially on 32-bit platforms built without LFS support. Many modules will continue to work on these huge datasets, but processing time may make it not worth the while. See Memory issues for more tips.
g.region -p

Watching top

top is a nice command line utility for watching a process's progression. While it won't give you many hard metrics it will give you an idea of what is happening. To make the view a little more stable, with top running from the command line press "M" to sort by memory usage.

Return codes

All GRASS modules send out a return code of "0" if they exit successfully and "1" if they have exited with an error. This is typically accompanied by an "ERROR: " message.

On UNIX (Linux, Mac OS, and Cygwin) directly after a command line module ends you can type "echo $?" and it will tell you the exit code. In a MS-Windows DOS box the equivalent command is "echo %errorlevel%".

Note that some modules (like g.findfile) exit with a status of 1 if it (for example) could not find a file, which may be exactly the test the module was run to perform. In that way the return code can be used in script logic. Thus the exit code only reports EXIT_SUCCESS or EXIT_FAILURE, but a failure can happen for any number of reasons, expected or unexpected, and is not a reason to panic in and of itself.

Using a C debugger on MS Windows

You'll need binaries built with debugging symbols [todo], then you can use tools like Dr. Watson and windbg.exe from Microsoft. Some hints for how this could work can be found here.

DLL dependencies

Sometimes it is needed to disentangle DLL dependencies. A reasonable tool is "Dependency Walker" (free as in free lunch, not software libero): http://www.dependencywalker.com

Using GDB

The GNU Debugger may be used to diagnose Segmentation Faults and other weirdness.

Compile Time Setup

To add debugging information into the built binary, first run

make distclean

Then configure the source code with -g being added to the CFLAGS arguments:

CFLAGS="-ggdb -Wall -Werror-implicit-function-declaration" ./configure ...

Do not use -O for optimization and do not strip the binaries with LDFLAGS="-s".

Eventually compile the source code and start the GRSS GIS session for debugging (see below).

Using gdb on command line

  • Running a program inside GDB works (installation of GDB required :-)
(e.g. on Debian GNU/Linux: apt-get install gdb)
  • Use the exact module name on the command line (at the GRASS prompt) without arguments. Put any command line arguments on the (gdb) command line after the word run.
 gdb `which v.in.ogr`
 run  out=some_map dsn="PG:dbname=postgis user=me" olayer=postgislayer
  • when it crashes, type "bt full" for a full 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.

or you can optionally add arguments to gdb directly on the commandline:

 gdb --args v.in.ogr out=bla dsn="PG:dbname=postgis user=me" olayer=postgislayer
  • Attaching to child process:
use "attach <pid>" to attach to an existing process (needed for DBMI debugging etc).
For details, see this hint

Saving a core dump for later analysis

On Linux, often if a program exits with a "Segmentation Fault" the program will exit leaving nothing behind. It is however possible to dump the state of the program (the memory "core") to a file. Ubuntu & Mac users may have seen with some crashing programs the long list of memory address computerese which it then asks if you want to report back to the authors.

On Linux, you can check if you are set to "dump the core" to a file with the ulimit command:

ulimit -c

a response of "0" means no core file will be written. Core files can be very large (depending on how much system RAM the program was using at the time it crashed), so is usually kept off. You can temporarily change the limit in a command terminal to dump the whole thing with:

ulimit -c unlimited

which will save a file called "core" in the present directory (if you have permission to write there). You can then analyze the core at a later time with:

gdb `which g.module` /path/to/core/file

It is important to note that you must analyze the core file against the exact version of the executable you were running at the time, and that if you send the core file to someone else they will be able to see the data you had loaded in the program at the time (if you are a consultant, you client might not like that).


Using gdb within GNU Emacs

Notes:

  • 'C' is usually key 'Ctrl'
  • 'M' is usually key 'Alt'
emacs general/manage/cmd/remove.c
Emacs gdb-1a.png
  • create second buffer by C-x 2
Emacs gdb-2.png
  • move cursor to the second buffer by C-x o, then M-x gdb, Enter
  • type module name which you would like to debug, e.g. g.remove, Enter
  • now you can use gdb inside GNU Emacs
Emacs gdb-3.png

Using DDD (gdb graphical frontend)

  • debugging a program inside DDD is rather easy (installation of ddd and gdb required), (on Debian GNU/Linux: apt-get install gdb ddd; on Fedora: dnf install ddd). Start debugger with GRASS command (e.g., v.in.ogr):
ddd v.in.ogr
ddd startup
  • Run (from main menu PROGRAM): "out=test dsn="PG:dbname=postgis user=me" olayer=postgislayer"
ddd define arguments
  • 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
ddd going up
  • right mouse button on variables permits to display them etc.
ddd display variables
  • 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.
  • You can select an individual variable to watch with
 View->Watched expressions
Type "data" in the text box at the top to view the entire structure of some variable called "data". If it is a structure you can then expand it and click on an interior variable. Clicking on its name makes it come up in the text box. Hit enter from the text box and it will be added to the list of watched expressions. You can edit a Y to X (then enter again) to quickly add another similarly named variable. e.g.:
(data->header).Ycoordinate

Using ldd

On Linux ldd will show the shared library dependencies for a program or library. For example:

For a module:

GRASS> ldd `which v.in.ogr`

For a library:

$ ldd /usr/src/grass/grass78/dist.x86_64-pc-linux-gnu/lib/libgrass_gis.so 

The output may look like this: linux-vdso.so.1 (0x00007ffe1cf03000) libgrass_datetime.7.8.so => /usr/src/grass/grass78/dist.x86_64-pc-linux-gnulib/libgrass_datetime.7.8.so (0x00007fae7a6cf000) libz.so.1 => /lib64/libz.so.1 (0x00007fae7a6b5000) libzstd.so.1 => /lib64/libzstd.so.1 (0x00007fae7a5df000) libm.so.6 => /lib64/libm.so.6 (0x00007fae7a499000) libc.so.6 => /lib64/libc.so.6 (0x00007fae7a2cf000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fae7a2ad000) /lib64/ld-linux-x86-64.so.2 (0x00007fae7a769000)

ldd is good for spotting if the right libraries are used (in the correct path etc).

  • On Mac OS "otool -L `which v.in.ogr`" almost does the same job.

Library search path

If a support library like libgdal can't be found, and you are sure it is installed, make sure the library search path is set correctly. For example in Linux if GDAL was installed to /usr/local, add the line "/usr/local/lib" to the /etc/ld.so.conf file, and as root run ldconfig to rebuild the library links and cache.

Alternatively you can add the library path to the $LD_LIBRARY_PATH environmental variable.

Using nm and objdump

nm will show a list symbols contained in a library or a program. Use this if you want to check which functions it calls. It will not work if the binary has been stripped.

For example:

GRASS> nm $GISBASE/lib/libgrass_gis.so
GRASS> nm `which r.digit`

If the binaries have been stripped you can still use the -D option to show dynamic symbols instead of normal symbols:

$ nm -D /bin/ls
  • see also the tools/sql.sh script in the GRASS souce code, which will run "nm" on every object file, library and executable to find dependencies. The result is stored in a PostgreSQL database.

objdump will work even if the binaries have been stripped. For example:

$ objdump -T /usr/lib/libX11.so
$ objdump -R /usr/lib/libX11.so

Using LD_DEBUG

To see in which order the various libraries are called, run the command with LD_DEBUG=files. For example:

LD_DEBUG=files r.info elevation

Using strace

Running the command through strace could give you another hint what is going wrong somewhere. It shows the command execution at low level.

For example:

strace v.in.ogr out=your_map dsn="PG:dbname=postgis user=me" olayer=postgislayer

Using Valgrind

  • Valgrind is a tool to check for memory leaks and memory errors.
Examples
  • analysis of heap usage
CMD="v.in.ascii -zt z=3 in=lidaratm2_250k.txt out=lidaratm2_250k fs=,"
valgrind --tool=massif $CMD --o
  • analysis of memory leaks (include --trace-children=yes to profile e.g. the DBF driver or other children)
    • Full memcheck tool, including non-orphaned, but left over, allocated memory:
valgrind --tool=memcheck --leak-check=yes --show-reachable=yes  $CMD --o
Notes
  • The default is to send Valgrind output to stderr. Add --log-file=<filename> to save output to a file, but note (if it matters) that you will lose any interleaved GRASS debug messages from the log that way.
  • Valgrind can create PostScript output charts. To convert PostScript to PNG:
('pstoimg' is part of the latex2html Debian package)
  • If you get something like this (huge value for "still reachable"):
> ==13217== LEAK SUMMARY:
> ==13217==    definitely lost: 964 bytes in 39 blocks
> ==13217==    indirectly lost: 72 bytes in 10 blocks
> ==13217==      possibly lost: 79 bytes in 4 blocks
> ==13217==    still reachable: 9,025,026,330 bytes in 188,201,312 blocks

then please run valgrind again with --show-reachable=yes as you will want to find out where these 9,025,026,330 bytes (in this example) have been allocated.


pstoimg -aaliastext -flip r90 -out massif.550.png -scale 1.3 -crop a massif.550.ps

Using Electric Fence

  • Electric Fence checks for bad memory writes, ie specific malloc() over-runs and under-runs.

(Insert howto here)

Example:

CMD="gdalwarp -tps -srcnodata 255 -dstnodata 255 \
       -of GTiff -rcs ${TMP}.tif ${OUTFILE}_warp"
LD_PRELOAD=libefence.so.0.0 $CMD

Using a profiling tool

A profiling tool may be used to identify the bottlenecks in long running processes.

Kcachegrind

kcachegrind is a visualization tool for Valgrind's callgrind profiling tool (formerly known as the calltree skin). It is very simple to use. Install the GraphViz package as well.

Example:

# Spearfish dataset
g.region raster=elevation.dem
v.random n=10000 out=rand10k
v.db.addtable rand10k column="elev INT"
CMD="v.what.rast rand10k rast=elevation.dem column=elev"
valgrind --tool=callgrind --trace-children=yes $CMD

This creates a file containing profiling information which kcachegrind can load. We include --trace-children in the above example so we can profile the DBF driver process as well as the main v.what.rast process.

kcachegrind callgrind.out.12345

In the above example from the two process costs we can see that 99.5% is taken by the dbf process and 0.5% is taken by the v.what.rast process. Within the dbf process almost 50% is taken by G_debug() and G_strcasecmp().

gprof

Compile GRASS with -pg flag. E.g.

CFLAGS='-pg' CXXFLAGS='-pg' LDFLAGS='-pg' ./configure --disable-shared
Example

Run the module

v.select -tg ain=geodetic_swwake_pts bin=urbanarea out=x ope=overlap --o

Use gprof to generate human readable output

gprof ../../dist.i686-pc-linux-gnu/bin/v.select gmon.out > profile.txt

Using Mudflap

GCC built in feature, that "instruments all risky pointer/array dereferencing operations, some standard library string/heap functions, and some other associated constructs with range/validity tests. Modules so instrumented should be immune to buffer overflows, invalid heap use, and some other classes of C/C++ programming errors. The instrumentation relies on a separate runtime library (libmudflap), which will be linked into a program if -fmudflap -lmudflap is given at link time." GCC Wiki

  • Requires GCC with mudflap support (GCC 4.x with mudflap USE flag on Gentoo, separate library "libmudflap*" in other distros);
  • Add -fmudflap and -lmudflap options (Is this correct way? It works...):
    • in include/Make/Platform.make add -lmudflap to LD_SEARCH_FLAGS;
    • in include/Make/Platform.make add -fmudflap to CFLAGS1;
  • Disable mudflap during compilation
export MUDFLAP_OPTIONS='-mode-nop -viol-nop'
  • Compile GRASS (make clean && make). For best results use NO optimisations for compilation (-O0);
  • Use GRASS.
    • To disable warnings
    export MUDFLAP_OPTIONS='-mode-nop -viol-nop'
    • To enable warnings
    export MUDFLAP_OPTIONS='-mode-check -viol-nop -check-initialization'

More information about debugging with mudflap, can be found here.

Skimming the ChangeLog for changes


Shell script debugging

Add "-x" to the first line of the shell script:

original:

 #!/bin/sh

change to:

 #!/bin/sh -x

alternatively add `set -x` to somewhere near the start of the script.

Find the script file to edit with

 which script

Python script debugging

Python debugging with pdb

See also:

1. Edit the GRASS python script and add this line to the import section:

import pdb

2. Edit and add this line within the code where to debug:

pdb.set_trace()

3. Run the python script normally, it will stop where pdb.set_trace() was added: r.unpack x60030_2000.green.histo2000_g.pack

GRASS 7.8 (patUTM32):~ > r.unpack x60030_2000.green.histo2000_g.pack
> /home/neteler/software/grass78/dist.x86_64-unknown-linux-gnu/scripts/r.unpack(93)main()
-> diff_result_1 = diff_result_2 = None

3. Now you can either (s)tep through or (n)ext or (r)run the rest (c: continue, q: quit)

(Pdb) s

While "s" will decend in functions, "n" will go to the next line. See the manual for Debugger Commands

4. To print the content of variables:

(Pdb) s
> /usr/lib64/python3.8/posixpath.py(73)join()
-> path = a
(Pdb) a
a = /grassdata/patUTM32/hist_matching
p = ('..', 'PERMANENT', 'PROJ_INFO')
(Pdb)

Now will likely be able to better find the issues in your Python script.

See also: https://docs.python.org/3/library/pdb.html

wxPython GUI debugging

A) Debug messages:

wxGUI prints debugging messages in five levels (1-5). To redirect these messages to the terminal, run

  • in GRASS 7.x
g.gisenv set=WX_DEBUG=1

B) Using a debugger:

For real debugging of wxgui.py (source code) with gdb or other tools, so you can use something like:

cd grass/src
python gui/wxpython/wxgui.py

or:

python $GISBASE/gui/wxpython/wxgui.py

Well, but that's just how to run the Python code directly.

Python debugging with gdb

See https://wiki.python.org/moin/DebuggingWithGdb

Komodo dbgp.client.brk()

from dbgp.client import brk

Profiling python scripts

PROJ debugging

See also: https://proj.org/usage/environmentvars.html?highlight=debugging

For unix with a style shell use export:

export PROJ_DEBUG=5
cs2cs ...