Welcome to the LTTng bug tracker!

Bug reporting guidelines¶

(This content was copied from https://lttng.org/community/#bug-reporting-guidelines for your convenience.)

Reporting bugs is an excellent way to contribute to the LTTng project. Should you be interested in reporting a bug, please make sure that it's complete by reading the following guidelines carefully.

The most important thing for developers is to understand how to reproduce the bug. If a developer can successfully reproduce a bug and knows what is the expected software behavior, he's given all the necessary tools to fix the issue.

Mandatory stuff¶

The following items must be provided for the bug to be reproducible:

• Component(s) involved: please report the bug under the appropriate Redmine project - if the bug involves more than one component, report it under the LTTng umbrella project
• Component version: full version of the software exhibiting the bug (--version option) or Git commit hash for custom builds
• System information:
  • Architecture, number of CPUs;
  • Operating system version (uname -a) and distribution.

Expected vs. actual results¶

Make sure you provide a short description explaining the nature of the bug: what is the expected behavior and what are you actually observing?

Avoid using negations in your description. Explain what should happen, not what shouldn't happen. Explain what is happening, not what's not happening.

Bad examples:

The event should not be disabled after tracing is stopped.

The command is not returning 0 after a successful execution.

Good examples:

The consumer daemon's execution should terminate after this operation.

Only 4 out of 5 events are recorded.

We need context!¶

When describing the actual results, add as much related context as possible. Useful context includes:

Logs¶

Copy the relevant logs to the bug's description.

• LTTng-UST: set the LTTNG_UST_DEBUG environment variable to 1 before running your application
• LTTng-tools: start the session daemon manually with the -vvv and --verbose-consumer arguments

Debugging information¶

When the bug involves a segmentation fault in LTTng-tools, the project should be compiled manually with the -g GCC option and without optimizations (-O0). This can be achieved by running configure like this:

CFLAGS="-g -O0" ./configure

Then, the following items are required:

• A core file
• Writing the full backtraces of the session daemon and the consumer daemon as returned by GDB (command thread apply all bt full)
• Running processes

It's often useful to have the list of LTTng-related processes running on the system:

ps -wwaux | grep '[l]ttng'

Loaded kernel modules¶

If the bug involves LTTng-modules (Linux kernel tracing), include the list of loaded LTTng-related kernel modules:

lsmod | grep lttng

Steps to reproduce the bug¶

This is the most important section. Its goal is to show the developers how to reproduce the bug, step by step.

You may write prerequisites to reduce the number of steps here. For example:

Prerequisite: a tracing session exists with two kernel domain channels named kern1 and kern2.

In this last example, the steps to create a tracing session and enable two kernel domain channels are summarized by a simple prerequisite.

Once you've laid out the steps to reproduce the bug, a good practice is to follow them and see if the bug is actually reproduced. This help ensure you didn't forget an important step.