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.
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 (
--versionoption) 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.
The event should not be disabled after tracing is stopped.
The command is not returning 0 after a successful execution.
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:
Copy the relevant logs to the bug's description.
- LTTng-UST: set the
LTTNG_UST_DEBUGenvironment variable to 1 before running your application
- LTTng-tools: start the session daemon manually with the
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
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.
Trace Compass UX Experiments (11/03/2015 08:34 PM)
Feature and bug tracking of the user experience experiments on Trace Compass. The purpose of this experimental branch is to prototype user experience enhancements to Trace Compass and gather quick feedback from end users.
Common Trace Format (06/05/2012 05:11 PM)
The Common Trace Format (CTF) is proposed as a trace format that suits the needs of the embedded, telecom, high-performance and kernel communities.
LTTngTop (02/16/2012 09:53 PM)
A small top-like utility using tracing to gather different metrics
Userspace RCU (02/09/2012 08:59 PM)
Userspace RCU synchronization library
Website (02/09/2012 08:38 PM)
To report bugs, missing items or features on the lttng.org or bugs.lttng.org websites