GRASS Debugging - Revision history

Neteler: +Python function tracing

2022-08-27T18:30:23Z

+Python function tracing

← Older revision		Revision as of 18:30, 27 August 2022
Line 561:		Line 561:
	* See http://docs.activestate.com/komodo/5.0/debugpython.html		* See http://docs.activestate.com/komodo/5.0/debugpython.html
	from dbgp.client import brk		from dbgp.client import brk

			=== Python function tracing ===

			Functions can be traced using the 'trace' module. It generates a trace of program execution, and annotated statement coverage and more.

			python -m trace --ignore-dir=../lib --trace mymain.py

			See also (for example): https://www.tutorialspoint.com/trace-or-track-python-statement-execution-trace

	=== Profiling python scripts ===		=== Profiling python scripts ===

Neteler: Update profiling workflow with gprof

2022-05-05T16:10:40Z

Update profiling workflow with gprof

← Older revision		Revision as of 16:10, 5 May 2022
Line 379:		Line 379:
	* [https://sourceware.org/binutils/docs/gprof/ 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)
			* https://www.nas.nasa.gov/hecc/support/kb/using-gprof-for-performance-analysis_671.html

	Compile GRASS with <code>-pg</code> flag. E.g.		Compile GRASS with <code>-pg</code> flag. E.g.
Line 390:		Line 391:
	v.select -tg ain=geodetic_swwake_pts bin=urbanarea out=x ope=overlap --o		v.select -tg ain=geodetic_swwake_pts bin=urbanarea out=x ope=overlap --o

	~~Use gprof to~~ generate ~~human readable output~~		It will generate the profiling data and store in the file <code>gmon.out</code>.

	gprof ../..~~/dist.i686-pc-linux-gnu/bin/~~v.~~select~~ gmon.out > profile.txt		Use gprof to generate human readable output from the file <code>gmon.out</code>:

			gprof $(which v.what) gmon.out

			To store the output in a reporting file, run
			gprof $(which v.what) gmon.out > profile.txt

	== Using Mudflap ==		== Using Mudflap ==

Neteler: fix GRASS GIS repo link

2022-05-05T15:56:51Z

fix GRASS GIS repo link

← Older revision		Revision as of 15:56, 5 May 2022
Line 1:		Line 1:
	The following hints assume to work on a working-copy of the ~~{{twiki\|DownloadSource#SubversionGRASSmainsourcecoderepository\|~~GRASS GIS source code~~} directory~~.		The following hints assume to work on a working-copy of the [https://github.com/OSGeo/grass GRASS GIS source code].

	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.

Neteler: + Duration with time

2022-05-05T13:20:51Z

+ Duration with time

← Older revision		Revision as of 13:20, 5 May 2022
Line 367:		Line 367:
	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 <tt>G_debug()</tt> and <tt>G_strcasecmp()</tt>.		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 <tt>G_debug()</tt> and <tt>G_strcasecmp()</tt>.

	=== gprof ===		=== Duration: time ===

			<code>time</code> with disk IO und socket message traffic (note: <code>time</code> with full path):

			/usr/bin/time -f "\nreal %E\nuser %U\nsys %S\nCPU %P\nRAM (KB) %M\nwaits %w\nswaps %W\ninputs %I\noutputs %O\nsocket rec %r\nsocket sent %s\nsignals %k\n" grass_command ...

			=== Profiling: gprof ===

	Profiling a program: Where does it spend its time?		Profiling a program: Where does it spend its time?

Neteler: /* gprof */

2022-05-05T13:06:11Z

gprof

← Older revision		Revision as of 13:06, 5 May 2022
Line 368:		Line 368:

	=== gprof ===		=== gprof ===

			Profiling a program: Where does it spend its time?

	* [https://sourceware.org/binutils/docs/gprof/ GNU gprof] user guide		* [https://sourceware.org/binutils/docs/gprof/ GNU gprof] user guide

Neteler: +memray: Memray is a memory profiler for Python

2022-04-28T10:14:09Z

+memray: Memray is a memory profiler for Python

← Older revision		Revision as of 10:14, 28 April 2022
Line 507:		Line 507:

	[[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 7.x

	g.gisenv set=WX_DEBUG=1		g.gisenv set=WX_DEBUG=1
Line 553:		Line 551:

	* See https://docs.python.org/library/profile.html		* See https://docs.python.org/library/profile.html

			=== Memory debugging of python scripts ===

			* memray: Memray is a memory profiler for Python
			** https://bloomberg.github.io/memray/

	== PROJ debugging ==		== PROJ debugging ==

Neteler: Explain "ll" in pdb

2022-03-17T13:39:47Z

Explain "ll" in pdb

← Older revision		Revision as of 13:39, 17 March 2022
Line 481:		Line 481:
	</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]		While "s" will descend in functions, "n" will go to the next line.

			To show the source code, use "ll".

			See the manual for [https://docs.python.org/3/library/pdb.html#debugger-commands Debugger Commands]

	4. To print the content of variables:		4. To print the content of variables:

Neteler: added d.mon example

2021-05-15T20:50:35Z

added d.mon example

← Older revision		Revision as of 20:50, 15 May 2021
Line 98:		Line 98:

	echo 0 \| sudo tee /proc/sys/kernel/yama/ptrace_scope		echo 0 \| sudo tee /proc/sys/kernel/yama/ptrace_scope


			d.mon example:

			<source lang="bash">
			# GRASS GIS session terminal
			d.mon start=wx0

			# Examine running wxGUI components by htop program and get pid
			# Run in another terminal or in terminal tab
			gdb --pid $(pgrep -f /gui/wxpython/mapdisp/main.py)
			continue

			# And then interact with the wxGUI component (d.mon)
			# If wxGUI component crash then you get backtrace with gdb bt command
			bt
			</source>

	=== Saving a core dump for later analysis ===		=== Saving a core dump for later analysis ===

Neteler: Attaching to child process

2021-05-15T07:16:44Z

Attaching to child process

← Older revision		Revision as of 07:16, 15 May 2021
Line 90:		Line 90:
	gdb -ex run --args v.in.ogr out=bla dsn="PG:dbname=postgis user=me" olayer=postgislayer		gdb -ex run --args v.in.ogr out=bla dsn="PG:dbname=postgis user=me" olayer=postgislayer

	* ''Attaching to child process~~'':~~		=== Attaching to child process ===
	: use "<tt>attach <pid></tt>" to attach to an existing process (needed for DBMI debugging etc).
			: in <tt>gdb</tt>, use "<tt>attach <pid></tt>" to attach to an existing process (needed for DBMI or d.mon debugging, etc).
	: For details, see this [http://lists.osgeo.org/pipermail/grass-dev/2007-October/033732.html hint]		: For details, see this [http://lists.osgeo.org/pipermail/grass-dev/2007-October/033732.html hint]

			How to solve “ptrace operation not permitted” when trying to attach GDB to a process? Run the following ([https://stackoverflow.com/questions/19215177/how-to-solve-ptrace-operation-not-permitted-when-trying-to-attach-gdb-to-a-pro source])

			echo 0 \| sudo tee /proc/sys/kernel/yama/ptrace_scope

	=== Saving a core dump for later analysis ===		=== Saving a core dump for later analysis ===

⚠️Tmszi: Extend wxPython GUI debugging subsection with gdb debugger example

2020-11-26T16:36:11Z

Extend wxPython GUI debugging subsection with gdb debugger example

← Older revision		Revision as of 16:36, 26 November 2020
Line 496:		Line 496:

	python $GISBASE/gui/wxpython/wxgui.py		python $GISBASE/gui/wxpython/wxgui.py

			or with gdb e.g.:

			<source lang="bash">
			# GRASS GIS session terminal
			d.mon start=wx0

			# Examine running wxGUI components by htop program and get pid
			# Run in another terminal or in terminal tab
			gdb --pid $(pgrep -f /gui/wxpython/mapdisp/main.py)
			continue

			# And then interact with the wxGUI component (d.mon)
			# If wxGUI component crash then you get backtrace with gdb bt command
			bt
			</source>

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