Debugging - Revision history

Jopa6460: /* Debugging with command line arguments */

2019-11-06T02:16:03Z

‎Debugging with command line arguments

2019-11-06T02:15:30Z

2013-07-15T20:40:46Z

2013-06-21T07:32:29Z

‎Debugging Seg Faults

2013-06-21T07:31:46Z

‎Debugging in parallel with GDB

2012-08-08T17:28:51Z

2012-08-08T17:28:27Z

2012-08-08T17:23:32Z

2012-08-08T17:23:03Z

2012-08-08T17:14:21Z

@@ Line 60: / Line 60: @@
 When the command
-addr2line -e /projects/jopa6460/SCOREC-core/build-14-190604dev_omp110/test/chef  0x6fabad
+  addr2line -e /projects/jopa6460/SCOREC-core/build-14-190604dev_omp110/test/chef  0x6fabad
 is run, the output is the path followed by the line in the code of where the code crashed. ex:
-/projects/jopa6460/SCOREC-core/core/phasta/phCook.cc:44
+  /projects/jopa6460/SCOREC-core/core/phasta/phCook.cc:44

@@ Line 52: / Line 52: @@
 ADD TO ME
-== '''Debugging in parallel with GDB''' ==
+== '''Debugging with command line arguments''' ==
 A useful command to debug a parallel job running with a low number of processes on the viz nodes at Colorado is the following:

← Older revision		Revision as of 20:40, 15 July 2013
Line 79:		Line 79:

	objdump -D <phasta exec name> \| vim -		objdump -D <phasta exec name> \| vim -
		+
		+	== Other Useful Wiki Pages ==
		+	[[Mtrace]] - Memory Leaks
		+
		+	[[Address Sanitizer]] - Bad memory accesses

@@ Line 72: / Line 72: @@
 == Debugging Seg Faults ==
-Reading core files generated after a seg fault can be done with gdb using the command
+Reading core files generated after a seg fault can be done with GDB using the command
    gdb <phasta exec name> <path to core file>

← Older revision		Revision as of 07:31, 21 June 2013
Line 70:		Line 70:

	for every process/terminal.		for every process/terminal.
		+
		+	== Debugging Seg Faults ==
		+	Reading core files generated after a seg fault can be done with gdb using the command
		+
		+	gdb <phasta exec name> <path to core file>
		+
		+	From here, there are a number of options including "disas" which shows the disassembly of the function where the seg fault occurred. Alternatively, it can be rather convenient to view the disassembly in vim or a vim like editor:
		+
		+	objdump -D <phasta exec name> \| vim -

@@ Line 63: / Line 63: @@
    set catchDebugger=1
+  mpirun -np <np> <phasta exec name>
-before running the command "mpirun <phasta exec name>" without any additional arguments.  it will launch debug windows automatically for you which when you release them will stop at the point of your "foul" which REALLY helps. See common/phasta.cc for more info.

@@ Line 56: / Line 56: @@
 A useful command to debug a parallel job running with a low number of processes on the viz nodes at Colorado is the following:
-mpirun -np <np> gnome-terminal --disable-factory -e 'gdb <exec name>'
+  mpirun -np <np> gnome-terminal --disable-factory -e 'gdb <exec name>'
 This will open a terminal running gdb for every process of your application. You can then execute in every terminal the usual gdb commands.
@@ Line 62: / Line 62: @@
 In particular, for PHASTA, you can also type in your terminal
-     set catchDebugger=1
+  set catchDebugger=1
- before running the command "mpirun <phasta exec name>" without any additional arguments.  it will launch debug windows automatically for you which when you release them will stop at the point of your "foul" which REALLY helps. See common/phasta.cc for more info.
+before running the command "mpirun <phasta exec name>" without any additional arguments.  it will launch debug windows automatically for you which when you release them will stop at the point of your "foul" which REALLY helps. See common/phasta.cc for more info.

← Older revision		Revision as of 17:23, 8 August 2012
Line 59:		Line 59:

	This will open a terminal running gdb for every process of your application. You can then execute in every terminal the usual gdb commands.		This will open a terminal running gdb for every process of your application. You can then execute in every terminal the usual gdb commands.
		+
		+	In particular, for PHASTA, you can also type in your terminal
		+
		+	set catchDebugger=1
		+
		+	before running the command "mpirun <phasta exec name>" without any additional arguments. it will launch debug windows automatically for you which when you release them will stop at the point of your "foul" which REALLY helps. See common/phasta.cc for more info.

← Older revision		Revision as of 17:14, 8 August 2012
Line 51:		Line 51:
	''Specific tips for PHASTA:''		''Specific tips for PHASTA:''
	ADD TO ME		ADD TO ME
		+
		+	== '''Debugging in parallel with GDB''' ==
		+
		+	A useful command to debug a parallel job running with a low number of processes on the viz nodes at Colorado is the following:
		+
		+	mpirun -np <np> gnome-terminal --disable-factory -e 'gdb <exec name>'
		+
		+	This will open a terminal running gdb for every process of your application. You can then execute in every terminal the usual gdb commands.