![]() |
![]() |
![]() |
![]() |
Log tracing information into an event file
![]() |
|
tracelogger [-cEPRrw] [-A attribute] [-b num] [-d mode]
[-F num] [-f file] [-k num] [-M -S size]
[-n num] [-s num] [-v[v...]]
QNX Neutrino
x86, PPC, SH-4, ARM, and MIPS
![]() |
You can't use the following in the name or value:
If you do, tracelogger prints a message and ignores the attribute. |
You can use one or more occurrences of this option to add information to identify the scenario that you're logging. For example:
tracelogger -s1 -A MACHINE_NAME=tx86 -A PERIOD=1s
You can specify more than one filter by using multiple -F options. For example, to disable both the Interrupt and VThread classes, specify -F2 -F5. For more information about these classes, see the Events and the Kernel chapter of the System Analysis Toolkit User's Guide.
The tracelogger daemon receives events from the instrumented kernel (procnto*-instr) and saves them in a file or on a device for later analysis. By default, tracelogger saves the events in /dev/shmem/tracebuffer.kev. The .kev extension is short for “kernel events”; the Integrated Development Environment opens files with this extension in the System Profiler.
You can run tracelogger in the following modes:
The simplest way to configure the tracing is to start tracelogger in normal or extended daemon (-d1 -E) mode, using the command-line options to specify what to trace. In this case, tracelogger performs all initialization and runtime control of the instrumentation module in addition to its normal task of saving the trace buffers to the filesystem. If you use extended daemon mode, your application needs to call TraceEvent() to start capturing trace events.
For finer (and more flexible) control of the instrumentation, run tracelogger in daemon (-d1) mode, and call TraceEvent() from your application to specify what to trace, and when to start and stop tracing. Except for specifying the number of buffers, tracelogger doesn't perform any initialization of the instrumentation module, and its almost exclusive task is to log the “received” trace events to the filesystem.
![]() |
On a multicore system, if the clocks on all processors aren't synchronized,
then tracelogger will produce
data with inconsistent timestamps, and the IDE won't be able to load the
trace file.
The IDE attempts to properly order the events in
the trace file, and this can go awry if the timestamp data is incorrect.
The traceprinter utility doesn't have any issues with such traces because it doesn't attempt to reorder the data and interpret it; it simply dumps the contents of each event. |
Start tracelogger in wide mode and display operational information on the console screen; store the logged data in the named file and stop logging when 12 trace buffers are full:
#tracelogger -f /dev/shmem/my_tracebuffer.kev -n 12 -w
Start tracelogger in ring mode (background) using 5 internal buffers and wait for an asynchronous signal (e.g. Ctrl-C) to stop it:
#tracelogger -r -b 5
Run tracelogger in continous mode for 20 seconds:
tracelogger -c -s20
Severe errors cause tracelogger to terminate.
Run only one instance of tracelogger at a time. Similarly, don't run tracelogger and use qconn (under control of the IDE) to trace events at the same time.
procnto*-instr, qconn, traceprinter
TraceEvent() in the QNX Neutrino Library Reference
System Analysis Toolkit User's Guide
Analyzing Your System with Kernel Tracing chapter of the IDE User's Guide
![]() |
![]() |
![]() |
![]() |