Revision as of 15:19, 17 June 2016

Debugging Information

There are numerous ways to detect and debug quality assurance issues. A list of these ways are found below.

Valgrind

When an application crashes, it is most often helpful to retrieve a backtrace, which shows the application state up to its crash.

The valgrind package must be installed, as well as any relevant *-debuginfo packages.

You should use the following script to debug:

#!/bin/sh
# Thanks to Jeffrey Johnson for this script.

valgrind -v --tool=memcheck --leak-check=full --show-reachable=yes --track-origins=yes $*

It may be handy to save this script to the PATH (don't forget to chmod +x it).

Then, run:

[path to script] [application, parameters, etc] &> /tmp/valgrind

You will be able to examine /tmp/valgrind for the backtrace, as well as other memory elements.

Examining Package File Ownership

Sometimes, the problem can be traced back to a file, bundled by the package.

A simple query can help you figure out the package that provided that file:

rpm -qf [path to file]

Note: If there are user modifications to the file, reinstall the package to make sure you're inspecting the package-provided version.

Inspecting Dependency Problems or File Conflicts

This article is now obsolete

must be updated

We can use FBA (Frontend Brother of ABF) to inspect the repositories and collect information about the current state and issues.

For dependency problems, we can inspect RepoClosure for:

And for File Conflicts:

Note: There may be problems for one architecture, but not another. Be sure to check both!