Debugging tips - Revision history

Ghudson at 22:22, 14 April 2020

2020-04-14T22:22:50Z

Ghudson: /* Building for Testing or Debugging */

2014-05-27T17:38:28Z

‎Building for Testing or Debugging

Ghudson: /* Using gcov for code coverage measurements */

2012-11-28T07:16:11Z

‎Using gcov for code coverage measurements

Ghudson: /* Using gcov for code coverage measurements */

2012-11-05T15:22:44Z

‎Using gcov for code coverage measurements

TomYu: /* Compile-Time Defines */

2010-08-10T19:32:32Z

‎Compile-Time Defines

Ghudson at 18:39, 7 June 2010

2010-06-07T18:39:23Z

Ghudson: /* Using gcov for code coverage measurements */

2009-06-18T17:37:09Z

‎Using gcov for code coverage measurements

Ghudson: /* Building for Testing or Debugging */

2009-06-18T17:36:22Z

‎Building for Testing or Debugging

Ghudson: /* Using gcov for code coverage measurements */

2009-06-11T17:53:24Z

‎Using gcov for code coverage measurements

Ghudson: /* Using gcov for code coverage measurements */

2009-06-10T19:47:48Z

‎Using gcov for code coverage measurements

← Older revision		Revision as of 22:22, 14 April 2020
Line 37:		Line 37:

	make CPPFLAGS=-DFLAGNAME		make CPPFLAGS=-DFLAGNAME
−
−	===DEBUG_ERROR_LOCATIONS===
−
−	The DEBUG_ERROR_LOCATIONS flag causes verbose error messages generated from the krb5 libraries to include file and line number information. It can be useful if you're having trouble tracking down where an error message is generated. It will not work in cases where an error code is generated with no call to krb5_set_error_message or krb5int_set_error; in that case you will have to track it down the slow way with gdb or whatever. If you are seeing an error with no corresponding krb5_set_error_message_call, consider whether the error case is "likely" and perhaps add a krb5_set_error_message to make it clearer what is going on.

	=== -DDEBUG ===		=== -DDEBUG ===

@@ Line 16: / Line 16: @@
 C++ code uses CXXFLAGS instead of CFLAGS.  There isn't a lot of C++ code in the Unix build, but if you do run into a need to debug what there is, be sure to override CXXFLAGS as well as CFLAGS.
-On Linux and perhaps other Unix variants, programs built with run-path options will consult the run path before LD_LIBRARY_PATH.  As a result, libraries from the install prefix will take precedence over libraries in the build tree.  This is particularly important to know when running the test suite.  To work around this issue, you can "make install" before "make check", or you can configure the tree to build without run-path options:
+On some platforms, programs built with run-path options will consult the run path before LD_LIBRARY_PATH.  (This is less of a concern than it used to be because we now build with -Wl,--enable-new-dtags on Linux and FreeBSD, which causes the generated binaries to prefer LD_LIBRARY_PATH to the run path.)  On these platforms, libraries from the install prefix will take precedence over libraries in the build tree.  This is particularly important to know when running the test suite.  To work around this issue, you can "make install" before "make check", or you can configure the tree to build without run-path options:
   .../configure --disable-rpath

← Older revision		Revision as of 07:16, 28 November 2012
Line 64:		Line 64:
	==Using gcov for code coverage measurements==		==Using gcov for code coverage measurements==

−	gcov is a gcc-based tool for computing code coverage. To use it with the krb5 tree:
		+	gcov is a gcc-based tool for computing code coverage. It can be used to determine the code coverage of the test suite, or to aid in debugging by showing what areas of code are executed during a manual test. If you are running an older operating system release, you may need a newer version of gcc in order to use gcov with shared libraries.

−	* Do a build with --enable-static --disable-shared, since gcov does not work with shared libraries.
		⚫	* Configure with CFLAGS="-g --coverage" LDFLAGS="--coverage". Building with these flags will create .gcno files in your build tree.
−	* Compile with:
		+	* Run whatever programs you want to compute coverage of. Running programs will create .gcda files in your build tree.
−	make CFLAGS="-g -fprofile-arcs -ftest-coverage" LDFLAGS="-fprofile-arcs -ftest-coverage"
		⚫	* cd into a subdirectory and run "gcov -f filename.c -o filename.so.gcov" to see the code coverage of that source file. (If the build directory is not the source directory, specify the full path to the source file.) gcov will display the percentage coverage of each function in its output, and will also create filename.c.gcov showing the number of times each line of code was executed. Note that static inline functions in our header files will be reported in each source file which includes those headers, artificially reducing the apparent coverage.
⚫	Building with these flags will create .gcno files in your build tree.
−	* Run whatever programs you want to compute coverage of. If you are running the full test suite, specify the same CFLAGS and LDFLAGS options to make check as you did for make, as test programs are generally not built as part of "make all". Running programs will create .gcda files in your build tree.
⚫	* cd into a subdirectory and run "gcov -f filename.c" to see the code coverage of that source file. gcov will display the percentage coverage of each function in its output, and will also create filename.c.gcov showing the number of times each line of code was executed~~. You can process this output any way you wish~~. Note that static inline functions in our header files will be reported in each source file which includes those headers; ~~you~~ ~~may want to filter those out to avoid~~ the ~~resulting deflation in~~ apparent ~~overall~~ coverage.
	* Note that coverage data is only written when a program exits normally. If the program exits due to an unhandled signal, coverage information from that run will be lost.		* Note that coverage data is only written when a program exits normally. If the program exits due to an unhandled signal, coverage information from that run will be lost.

@@ Line 70: / Line 70: @@
   make CFLAGS="-g -fprofile-arcs -ftest-coverage" LDFLAGS="-fprofile-arcs -ftest-coverage"
 Building with these flags will create .gcno files in your build tree.
-* Run whatever programs you want to compute coverage of.  If you are running the full test suite, specify the same CFLAGS and LDFLAGS options to make check as you did for make, as test programs are generally not built as part of "make all".  Running programs will create .gcda files in your build tree.  If you are running the krb-root tests, you must pre-create some .gcda files to avoid them being created as root and being unwritable by you; simplest is probably to run:
+* Run whatever programs you want to compute coverage of.  If you are running the full test suite, specify the same CFLAGS and LDFLAGS options to make check as you did for make, as test programs are generally not built as part of "make all".  Running programs will create .gcda files in your build tree.
 * cd into a subdirectory and run "gcov -f filename.c" to see the code coverage of that source file.  gcov will display the percentage coverage of each function in its output, and will also create filename.c.gcov showing the number of times each line of code was executed.  You can process this output any way you wish.  Note that static inline functions in our header files will be reported in each source file which includes those headers; you may want to filter those out to avoid the resulting deflation in apparent overall coverage.
 * Note that coverage data is only written when a program exits normally.  If the program exits due to an unhandled signal, coverage information from that run will be lost.

← Older revision		Revision as of 19:32, 10 August 2010
Line 41:		Line 41:

	The DEBUG_ERROR_LOCATIONS flag causes verbose error messages generated from the krb5 libraries to include file and line number information. It can be useful if you're having trouble tracking down where an error message is generated. It will not work in cases where an error code is generated with no call to krb5_set_error_message or krb5int_set_error; in that case you will have to track it down the slow way with gdb or whatever. If you are seeing an error with no corresponding krb5_set_error_message_call, consider whether the error case is "likely" and perhaps add a krb5_set_error_message to make it clearer what is going on.		The DEBUG_ERROR_LOCATIONS flag causes verbose error messages generated from the krb5 libraries to include file and line number information. It can be useful if you're having trouble tracking down where an error message is generated. It will not work in cases where an error code is generated with no call to krb5_set_error_message or krb5int_set_error; in that case you will have to track it down the slow way with gdb or whatever. If you are seeing an error with no corresponding krb5_set_error_message_call, consider whether the error case is "likely" and perhaps add a krb5_set_error_message to make it clearer what is going on.
		+
		+	=== -DDEBUG ===
		+
		+	Running
		+
		+	make CPPFLAGS=-DDEBUG
		+
		+	from the top of the build tree or
		+
		+	.../configure CPPFLAGS=-DDEBUG
		+
		+	is not recommended. Some code under <code>-DDEBUG</code> will not compile or link successfully. It is better to run
		+
		+	make CPPFLAGS=-DDEBUG
		+
		+	in a single subdirectory containing the code of interest.

	==Debugging the KDC==		==Debugging the KDC==

← Older revision		Revision as of 18:39, 7 June 2010
Line 23:		Line 23:

	If you are using certain kinds of instrumentation (such as gcov), you might need to do a build with static instead of shared libraries. You can do this with the --enable-static --disable-shared configuration flags. This flag will cause in-tree KDB plugins to be linked statically to the KDB library instead of loaded dynamically. At the moment, other kinds of plugins (such as preauth plugins) simply won't function.		If you are using certain kinds of instrumentation (such as gcov), you might need to do a build with static instead of shared libraries. You can do this with the --enable-static --disable-shared configuration flags. This flag will cause in-tree KDB plugins to be linked statically to the KDB library instead of loaded dynamically. At the moment, other kinds of plugins (such as preauth plugins) simply won't function.
		+
		+	==Trace Logging==
		+
		+	Even with a regular production build (for krb5 1.9 or trunk code after 2010-06-07), you can display trace events by setting the KRB5_TRACE environment variable to a filename. For example, try "env KRB5_TRACE=/dev/stdout kinit" to see some behind-the-scenes information about getting initial credentials. The KRB5_TRACE environment variable will not work for secure contexts, such as those created by ksu or login systems.

	==Compile-Time Defines==		==Compile-Time Defines==

@@ Line 46: / Line 46: @@
 gcov is a gcc-based tool for computing code coverage.  To use it with the krb5 tree:
-* Do a build with --enable-static-only, since gcov does not work with shared libraries.
+* Do a build with --enable-static --disable-shared, since gcov does not work with shared libraries.
 * Compile with:
   make CFLAGS="-g -fprofile-arcs -ftest-coverage" LDFLAGS="-fprofile-arcs -ftest-coverage"

@@ Line 22: / Line 22: @@
 A tree built this way may not be as useful when installed (since the binaries won't know how to find the libraries), but is more convenient for running programs out of the build tree.  Note that plugins will still be loaded from the install prefix by default.  The test suite overrides the plugin paths using special krb5.conf directives; if you are running a program by hand from the build tree and it uses plugins, you must either do the same overriding or run "make install" before running the program.
-If you are using certain kinds of instrumentation (such as gcov), you might need to do a build with static instead of shared libraries.  You can do this with the --enable-static-only configuration flag.  This flag will cause in-tree KDB plugins to be linked statically to the KDB library instead of loaded dynamically.  At the moment, other kinds of plugins (such as preauth plugins) simply won't function.
+If you are using certain kinds of instrumentation (such as gcov), you might need to do a build with static instead of shared libraries.  You can do this with the --enable-static --disable-shared configuration flags.  This flag will cause in-tree KDB plugins to be linked statically to the KDB library instead of loaded dynamically.  At the moment, other kinds of plugins (such as preauth plugins) simply won't function.
 ==Compile-Time Defines==

← Older revision		Revision as of 17:53, 11 June 2009
Line 53:		Line 53:
	find . -name "*.gcno" \| sed -e 's/gcno$/gcda/' \| xargs touch		find . -name "*.gcno" \| sed -e 's/gcno$/gcda/' \| xargs touch
	* cd into a subdirectory and run "gcov -f filename.c" to see the code coverage of that source file. gcov will display the percentage coverage of each function in its output, and will also create filename.c.gcov showing the number of times each line of code was executed. You can process this output any way you wish. Note that static inline functions in our header files will be reported in each source file which includes those headers; you may want to filter those out to avoid the resulting deflation in apparent overall coverage.		* cd into a subdirectory and run "gcov -f filename.c" to see the code coverage of that source file. gcov will display the percentage coverage of each function in its output, and will also create filename.c.gcov showing the number of times each line of code was executed. You can process this output any way you wish. Note that static inline functions in our header files will be reported in each source file which includes those headers; you may want to filter those out to avoid the resulting deflation in apparent overall coverage.
		+	* Note that coverage data is only written when a program exits normally. If the program exits due to an unhandled signal, coverage information from that run will be lost.