LTTng bugs repository: Issueshttps://bugs.lttng.org/https://bugs.lttng.org/themes/lttng/favicon/a.ico?14249722912024-02-21T17:04:43ZLTTng bugs repository
Redmine Babeltrace - Feature #1410 (New): Add pretty-print sink options to override how to format floatin...https://bugs.lttng.org/issues/14102024-02-21T17:04:43ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>Babeltrace 2, just like its predecessor babeltrace 1.5, uses "%g" to print floating point numbers.</p>
<p>It would be useful to let users optionally override the formatting for floating point numbers, perhaps with a pretty print sink option. They could then choose if exponent notation should be used or not, choose the precision, etc.</p> Babeltrace - Bug #1389 (New): src.ctf.fs crash with invalid tracehttps://bugs.lttng.org/issues/13892023-09-18T20:16:39ZSimon Marchisimon.marchi@polymtl.ca
<p>Using the attached trace, I get:</p>
<pre>
$ ./src/cli/babeltrace2 trace
09-18 16:15:58.978 335803 335803 E PLUGIN/CTF/MSG-ITER ctf_msg_iter_get_next_message@msg-iter.cpp:2715 [auto-disc-source-ctf-fs] Cannot handle state: msg-it-addr=0x613000000580, state=DSCOPE_EVENT_PAYLOAD_CONTINUE
09-18 16:15:58.978 335803 335803 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:63 Babeltrace 2 library postcondition not satisfied.
09-18 16:15:58.978 335803 335803 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:65 ------------------------------------------------------------------------
09-18 16:15:58.978 335803 335803 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:66 Condition ID: `post:message-iterator-class-next-method:no-error-if-no-error-status`.
09-18 16:15:58.978 335803 335803 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:68 Function: bt_message_iterator_class_next_method().
09-18 16:15:58.978 335803 335803 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:69 ------------------------------------------------------------------------
09-18 16:15:58.978 335803 335803 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:70 Error is:
09-18 16:15:58.978 335803 335803 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:72 Current thread has an error, but user function returned a non-error status: status=OK
09-18 16:15:58.978 335803 335803 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:75 Aborting...
</pre> LTTng-modules - Bug #1358 (New): Failed to deploy lttng modules on NVIDIA jetson devicehttps://bugs.lttng.org/issues/13582022-09-13T13:22:48Zliuhonggang liu
<p>Hello, I installed lttng and lttng modules on NVIDIA Orin. <br />When using apt install, the results are as follows.<br /><pre><code class="shell syntaxhl" data-language="shell"><span class="c"># lttng list --kernel</span>
Error: Unable to list kernel events: Kernel tracer not available
</code></pre></p>
<pre><code class="shell syntaxhl" data-language="shell"><span class="c">#ps aux | grep lttng-sessiond</span>
root 52100 0.0 0.0 1022064 12736 ? Ssl 15:05 0:00 /usr/bin/lttng-sessiond
root 52101 0.0 0.0 41968 664 ? S 15:05 0:00 /usr/bin/lttng-sessiond
orin-d 62549 0.0 0.0 11640 684 pts/0 S+ 20:54 0:00 <span class="nb">grep</span> <span class="nt">--color</span><span class="o">=</span>auto lttng-sessiond
</code></pre>
<pre>
# dpkg -l | grep lttng
ii liblttng-ctl0:arm64 2.12.4-1~ubuntu20.04.1 arm64 LTTng control and utility library
ii liblttng-ust-ctl4:arm64 2.12.2-1~ubuntu20.04.1 arm64 LTTng 2.0 Userspace Tracer (trace control library)
ii liblttng-ust-dev:arm64 2.12.2-1~ubuntu20.04.1 arm64 LTTng 2.0 Userspace Tracer (development files)
ii liblttng-ust-python-agent0:arm64 2.12.2-1~ubuntu20.04.1 arm64 LTTng 2.0 Userspace Tracer (Python agent native library)
ii liblttng-ust0:arm64 2.12.2-1~ubuntu20.04.1 arm64 LTTng 2.0 Userspace Tracer (tracing libraries)
ii lttng-modules-dkms 2.12.6-1~ubuntu20.04.1 all Linux Trace Toolkit (LTTng) kernel modules (DKMS)
ii lttng-tools 2.12.4-1~ubuntu20.04.1 arm64 LTTng control and utility programs
ii python3-lttng 2.12.4-1~ubuntu20.04.1 arm64 LTTng control and utility Python bindings
</pre>
<p>The device information is as follows.<br /><pre><code class="shell syntaxhl" data-language="shell"><span class="c"># uname -a</span>
Linux orind-d 5.10.65-tegra <span class="c">#2 SMP PREEMPT Thu Jun 16 18:24:26 CST 2022 aarch64 aarch64 aarch64 GNU/Linux</span>
</code></pre><br /><pre><code class="shell syntaxhl" data-language="shell"><span class="c"># cat /etc/os-release</span>
<span class="nv">NAME</span><span class="o">=</span><span class="s2">"Ubuntu"</span>
<span class="nv">VERSION</span><span class="o">=</span><span class="s2">"20.04.4 LTS (Focal Fossa)"</span>
<span class="nv">ID</span><span class="o">=</span>ubuntu
<span class="nv">ID_LIKE</span><span class="o">=</span>debian
<span class="nv">PRETTY_NAME</span><span class="o">=</span><span class="s2">"Ubuntu 20.04.4 LTS"</span>
<span class="nv">VERSION_ID</span><span class="o">=</span><span class="s2">"20.04"</span>
<span class="nv">HOME_URL</span><span class="o">=</span><span class="s2">"https://www.ubuntu.com/"</span>
<span class="nv">SUPPORT_URL</span><span class="o">=</span><span class="s2">"https://help.ubuntu.com/"</span>
<span class="nv">BUG_REPORT_URL</span><span class="o">=</span><span class="s2">"https://bugs.launchpad.net/ubuntu/"</span>
<span class="nv">PRIVACY_POLICY_URL</span><span class="o">=</span><span class="s2">"https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"</span>
<span class="nv">VERSION_CODENAME</span><span class="o">=</span>focal
<span class="nv">UBUNTU_CODENAME</span><span class="o">=</span>focal
</code></pre></p>
<p>At the same time, I tried the method of source code, such as the source code installation method introduced in <a class="external" href="https://lttng.org/docs/v2.13/">https://lttng.org/docs/v2.13/</a>.<br /><pre>
# dpkg -l | grep -e libuuid -e popt -e userspace -e libxml2
ii can-utils 2018.02.0-1ubuntu1 arm64 SocketCAN userspace utilities and tools
ii dmsetup 2:1.02.167-1ubuntu1 arm64 Linux Kernel Device Mapper userspace library
ii gvfs:arm64 1.44.1-1ubuntu1 arm64 userspace virtual filesystem - GIO module
ii gvfs-backends 1.44.1-1ubuntu1 arm64 userspace virtual filesystem - backends
ii gvfs-bin 1.44.1-1ubuntu1 arm64 userspace virtual filesystem - deprecated command-line tools
ii gvfs-common 1.44.1-1ubuntu1 all userspace virtual filesystem - common data files
ii gvfs-daemons 1.44.1-1ubuntu1 arm64 userspace virtual filesystem - servers
ii gvfs-fuse 1.44.1-1ubuntu1 arm64 userspace virtual filesystem - fuse server
ii gvfs-libs:arm64 1.44.1-1ubuntu1 arm64 userspace virtual filesystem - private libraries
ii libdevmapper1.02.1:arm64 2:1.02.167-1ubuntu1 arm64 Linux Kernel Device Mapper userspace library
ii libi2c0:arm64 4.1-2build2 arm64 userspace I2C programming library
ii libibverbs1:arm64 28.0-1ubuntu1 arm64 Library for direct userspace use of RDMA (InfiniBand/iWARP)
ii libnftnl11:arm64 1.1.5-1 arm64 Netfilter nftables userspace API library
ii libpopt-dev:arm64 1.16-14 arm64 lib for parsing cmdline parameters - development files
ii libpopt0:arm64 1.16-14 arm64 lib for parsing cmdline parameters
ii liburcu-dev:arm64 0.12.2-1~ubuntu20.04.2 arm64 userspace RCU (read-copy-update) library - development files
ii liburcu6:arm64 0.12.2-1~ubuntu20.04.2 arm64 userspace RCU (read-copy-update) library
ii libusb-1.0-0:arm64 2:1.0.23-2build1 arm64 userspace USB programming library
ii libusb-1.0-0-dev:arm64 2:1.0.23-2build1 arm64 userspace USB programming library development files
ii libuuid1:arm64 2.34-0.1ubuntu9.3 arm64 Universally Unique ID library
ii libxml2:arm64 2.9.10+dfsg-5ubuntu0.20.04.1 arm64 GNOME XML library
ii libxml2-dev:arm64 2.9.10+dfsg-5ubuntu0.20.04.1 arm64 Development files for the GNOME XML library
ii libxml2-utils 2.9.10+dfsg-5ubuntu0.20.04.3 arm64 XML utilities
ii network-manager 1.22.10-1ubuntu2.3 arm64 network management framework (daemon and userspace tools)
ii nvidia-l4t-optee 34.1.0-20220406120854 arm64 OP-TEE userspace daemons, test programs and libraries
ii python3-lxml:arm64 4.5.0-1ubuntu0.5 arm64 pythonic binding for the libxml2 and libxslt libraries
</pre></p>
<pre>
sudo ln -snf /usr/src/linux-headers-5.10.65-tegra-ubuntu20.04_aarch64/kernel-5.10 /lib/modules/5.10.65-tegra/build
</pre>
<pre>
# orin-d@orind-d:~/tmp/lttng-modules-2.13.5$ make
/home/orin-d/tmp/lttng-modules-2.13.5/src/wrapper/kallsyms.c:20:3: error: #error "LTTng-modules requires CONFIG_KPROBES on kernels >= 5.7.0"
20 | # error "LTTng-modules requires CONFIG_KPROBES on kernels >= 5.7.0"
| ^~~~~
make[2]: *** [scripts/Makefile.build:281: /home/orin-d/tmp/lttng-modules-2.13.5/src/wrapper/kallsyms.o] Error 1
make[1]: *** [Makefile:1852: /home/orin-d/tmp/lttng-modules-2.13.5/src] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-5.10.65-tegra-ubuntu20.04_aarch64/kernel-5.10'
make: *** [Makefile:31: modules] Error 2
</pre> Babeltrace - Feature #1300 (New): babeltrace2 lacks knowledge of bitwise enum produced by lttng-m...https://bugs.lttng.org/issues/13002021-03-23T17:41:47ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>This is a follow up on <a class="external" href="https://review.lttng.org/c/babeltrace/+/3045">https://review.lttng.org/c/babeltrace/+/3045</a> now that end users are starting to contact us wondering why up-to-date lttng and babeltrace2 show incomplete information for bitwise enums.</p>
<p>I think we should implement a better stop-gap solution while awaiting CTF2. I recommend that we specialize the babeltrace2 CTF input plugin to detect traces produced by the lttng-modules kernel tracer, for specific known (hardcoded) events and fields which have a bitwise enum semantic, and use this hardcoded knowledge to print the correct bitwise enum to the end user rather than "<unknown>".</p>
<p>This should ensure the current producer/consumer tools work well together (show complete information about those bitwise enums) without requiring to modify tons of documentation about the specific flags needed for bt2 to handle lttng traces appropriately. And this would not lead to misleading scenarios where we print an unknown value as a bitwise enum by mistake.</p>
<p>Hardcoded producer detection/event/fields is of course a last resort solution awaiting proper self-description in the upcoming CTF2 spec.</p> Babeltrace - Bug #1289 (New): docs: document that the "notext" flag is required to build out of t...https://bugs.lttng.org/issues/12892020-11-04T22:06:23ZJérémie Galarneaujeremie.galarneau@efficios.com
<p>This is related to the gerrit change <a href="https://review.lttng.org/c/babeltrace/+/4228" class="external">4228</a></p>
<p>When building an out-of-tree plug-in, users of LLVM ld (freeBSD, but also maybe macOS?) must ensure they pass the 'notext' flag.<br />See the discussion on the gerrit change for more context.</p>
<p>This should probably be documented under <a href="https://github.com/efficios/babeltrace/blob/43c59509042845f8d42c3e99ec74d45fa2dc0908/doc/api/libbabeltrace2/dox/guides.dox#L101" class="external">Compile and link a Babeltrace 2 shared object plugin of guides.dox</a></p> Babeltrace - Feature #1233 (New): Python: Add __str__ to Message types, and perhaps other typeshttps://bugs.lttng.org/issues/12332020-02-17T21:49:43ZSimon Marchisimon.marchi@polymtl.ca
<p>Example use case: I assume that when implementing a sink, people will print() the messages they receive at first. It would be nice if the output was more useful than:</p>
<pre>
<bt2.message._EventMessage object @ 0x607000006530>
<bt2.message._PacketEndMessage object @ 0x6070000065a0>
<bt2.message._PacketBeginningMessage object @ 0x607000006760>
<bt2.message._PacketBeginningMessage object @ 0x6070000049a0>
<bt2.message._EventMessage object @ 0x607000004c40>
<bt2.message._EventMessage object @ 0x607000006a00>
<bt2.message._PacketEndMessage object @ 0x607000006a70>
<bt2.message._PacketBeginningMessage object @ 0x607000006c30>
<bt2.message._EventMessage object @ 0x607000006530>
<bt2.message._PacketEndMessage object @ 0x607000004cb0>
<bt2.message._PacketBeginningMessage object @ 0x607000004e70>
</pre> Babeltrace - Bug #1232 (New): src.ctf.fs: variant option names without their tag equivalent are a...https://bugs.lttng.org/issues/12322020-02-17T21:40:34ZPhilippe Proulxeeppeliteloop@gmail.com
<p>See the attached trace. The metadata is valid for <code>src.ctf.fs</code>, however there's a variant option name (<code>d</code>) without its member in the tag, and there's a tag member (<code>a</code>) without an equivalent variant option name. The trace contains the byte 0 followed with a string. This means the tag's value is <code>a</code>, but then the variant option does not exist. This happens:</p>
<pre>
03-26 15:20:28.111 13242 13242 W PLUGIN-CTF-FS-SRC add_ds_file_to_ds_file_group@fs.c:672 Failed to index CTF stream file '/tmp/zzz/allo'
03-26 15:20:28.111 13242 13242 W PLUGIN-CTF-MSG-ITER bfcr_borrow_variant_selected_field_class_cb@msg-iter.c:2354 Cannot find variant field class's option: notit-addr=0x5557cd2a14f0, var-fc-addr=0x5557cd2ad0a0, u-tag=0, i-tag=0
03-26 15:20:28.111 13242 13242 W PLUGIN-CTF-MSG-ITER read_dscope_begin_state@msg-iter.c:581 BFCR failed to start: notit-addr=0x5557cd2a14f0, bfcr-addr=0x5557cd2a1680, status=BT_BFCR_STATUS_ERROR
03-26 15:20:28.111 13242 13242 W PLUGIN-CTF-MSG-ITER read_event_payload_begin_state@msg-iter.c:1393 Cannot decode event payload field: notit-addr=0x5557cd2a14f0, event-class-addr=0x5557cd2a7200, event-class-name="allo", event-class-id=0, fc-addr=0x5557cd2a7990
03-26 15:20:28.111 13242 13242 W PLUGIN-CTF-MSG-ITER bt_msg_iter_get_next_message@msg-iter.c:2769 Cannot handle state: notit-addr=0x5557cd2a14f0, state=STATE_DSCOPE_EVENT_PAYLOAD_BEGIN
babeltrace: msg-iter.c:1366: read_event_payload_begin_state: Assertion `!notit->dscopes.event_payload' failed.
</pre> Babeltrace - Bug #1230 (New): flt.utils.trimmer: local time can be nonexistent or ambiguous with DSThttps://bugs.lttng.org/issues/12302020-02-17T21:23:16ZPhilippe Proulxeeppeliteloop@gmail.com
<p>In Canada, this time is nonexistent:</p>
<pre>
2019-03-10 2:30
</pre>
<p>This specific time does not exist because DST starts on <code>2019-03-10 2:00</code> (so the local time becomes <code>2019-03-10 3:00</code>, with DST).</p>
<p>This time is ambiguous:</p>
<pre>
2019-11-03 1:30
</pre>
<p>This time occurs twice because DST ends <code>2019-11-03 2:00</code> (so the local time becomes <code>2019-11-03 1:00</code> <em>again</em>, but without DST).</p>
<p>Currently <code>flt.utils.trimmer</code> guesses times when you specify one of these:</p>
<ol>
<li>When you specify <code>2019-03-10 2:30</code> to <code>mktime()</code>, it returns a timestamp which, converted back to a local date/time, is <code>2019-03-10 3:30</code> (with DST). I believe this is unexpected and a completely arbitrary decision.</li>
<li>When you specify <code>2019-11-03 1:30</code> to <code>mktime()</code> and set the <code>tm_isdst</code> member to <code>-1</code>, it returns a timestamp which, converted back to a local date/time, is <code>2019-11-03 1:30</code> (with DST). This is also a completely arbitrary decision.</li>
</ol>
<p>I am disappointed that <code>mktime()</code> does not return an error with a specific code for what's happening in those situations.</p>
<p>To avoid such completely arbitrary decisions, we need a date/time format with which you can specify the time zone, or at least that for your local time zone, when the time is ambiguous, you want it on the DST side or not.</p>
<p><a class="user active" href="https://bugs.lttng.org/users/8">Simon Marchi</a> suggested to use <a href="https://en.wikipedia.org/wiki/ISO_8601" class="external">ISO 8601</a>, as more and more of our tools use this standard, and GLib <a href="https://developer.gnome.org/glib/stable/glib-Date-and-Time-Functions.html#g-time-val-to-iso8601" class="external">has functions</a> to deal with this format. I also checked and it supports having nanoseconds (any number of digits in fact) after seconds (and even after minutes and hours), for example:</p>
<pre>
2019-05-01T18:52:47.192838473
2019-05-01T18:52:47.192838473-04
2019-05-01T18:52:47.192838473Z
18:52:47.192838473
18:52:47.192838473-04
18:52:47.192838473Z
</pre>
<p>All those are valid ISO 8601 date/times. I don't know if GLib can parse nanoseconds however; we could have to parse this part ourselves.</p>
<p>To fix issue 1 (<code>2019-03-10 2:30</code>: nonexistent time), we need to detect that the time does not exist, instead of silently adding one hour, and fail (report nonexistent time).</p>
<p>To fix issue 2 (<code>2019-11-03 1:30</code>: ambiguous time), we need to fail (report ambiguous time) and ask the user to specify the time zone to indicate if DST was ended or not, one of (for Canada):</p>
<pre>
2019-11-03T01:30-04
2019-11-03T01:30-05
</pre>
<p>I hope GLib functions can detect that when you don't specify a time zone (local time).</p> Babeltrace - Bug #1229 (New): flt.utils.trimmer: with no date, beginning time cannot be greater t...https://bugs.lttng.org/issues/12292020-02-17T21:18:06ZPhilippe Proulxeeppeliteloop@gmail.com
<p>If you specify</p>
<pre>
begin="22:34", end="02:17"
</pre>
<p>to <code>flt.utils.trimmer</code>, it fails to initialize and logs that the the beginning time is greater than the end time.</p>
<p>However, it is implicit that, without dates specified, any combination of beginning and end times is correct, and we assume a maximum delta of 23h59:59.999999999. In other words, in the example above, we want to trim from 22:34 to 2:17 the following day.</p>
<p>Would this be accepted:</p>
<pre>
begin="2019-04-11 22:34", end="02:17"
</pre>
<p>Or this:</p>
<pre>
begin="22:34", end="2019-04-12 02:17"
</pre>
<p>If so, we don't need any message to deduce the end time's date. But this is not currently supported.</p> Babeltrace - Bug #1227 (New): cli: Error when using --clock-cycles and -c sink.text.pretty at the...https://bugs.lttng.org/issues/12272020-02-17T21:11:48ZSimon Marchisimon.marchi@polymtl.ca
<p>When using both <code>--clock-cycles</code> and <code>-c sink.text.pretty</code> at the same time, the cli tries to instantiate two pretty components:</p>
<pre>
Source component instances:
'source.test-trimmer.TheSourceOfAllEvil':
Name: source.test-trimmer.TheSourceOfAllEvil
Parameters:
{ }
Filter component instances:
'filter.utils.muxer':
Name: muxer
Parameters:
{ }
'filter.utils.trimmer':
Name: trimmer
Parameters:
begin: 350
Sink component instances:
'sink.text.pretty':
Name: sink.text.pretty
Parameters:
{ }
'sink.text.pretty':
Name: pretty
Parameters:
verbose: yes
clock-cycles: yes
Connections:
source.test-trimmer.TheSourceOfAllEvil.* -> muxer.*
muxer.* -> trimmer.*
trimmer.* -> sink.text.pretty.*
trimmer.* -> pretty.*
</pre>
<p>one of which has an input not connected. It later hits the assertion:</p>
<pre>
06-28 23:41:33.022 26827 26827 F LIB/MSG-ITER bt_self_component_port_input_message_iterator_create@iterator.c:427 Babeltrace 2 library precondition not satisfied; error is:
06-28 23:41:33.022 26827 26827 F LIB/MSG-ITER bt_self_component_port_input_message_iterator_create@iterator.c:427 Port is not connected: port-addr=0x607000002390, port-type=BT_PORT_TYPE_INPUT, port-name="in"
06-28 23:41:33.022 26827 26827 F LIB/MSG-ITER bt_self_component_port_input_message_iterator_create@iterator.c:427 Aborting...
</pre> LTTng-UST - Bug #1132 (New): Fails to build with Crosscompilerhttps://bugs.lttng.org/issues/11322017-10-27T11:46:39ZNorbert Lange
<p>The Userspace libary will fail to build when crosscompiling, this is easily repruducable with Buildroot for example.</p>
<p>As far as I can tell, the transitive dependency to liblttng-ust-tracepoint.so.0 when referencing liblttng-ust.so is lost, <br />I suppose it would not appear if the host or sysroot contains an installed liblttng-ust-tracepoint.so.0.</p>
<p>Error Message is following:</p>
<p>[ 70%] Linking CXX executable tester<br />/usr/bin/cmake -E cmake_link_script CMakeFiles/tester.dir/link.txt --verbose=1<br />/tmp/build/host/bin/x86_64-buildroot-linux-gnu-g++ -g -O2 -rdynamic CMakeFiles/tester.dir/tester.cpp.o -o tester -Wl,-rpath,/tmp/a/doc/examples/cmake-multiple-shared-libraries/build:/tmp/a/liblttng-ust/.libs libaligner-lib.so libtester-lib.so libtracepoint-provider.so /tmp/a/liblttng-ust/.libs/liblttng-ust.so -ldl <br />/tmp/build/host/lib/gcc/x86_64-buildroot-linux-gnu/7.2.0/../../../../x86_64-buildroot-linux-gnu/bin/ld: warning: liblttng-ust-tracepoint.so.0, needed by /tmp/a/liblttng-ust/.libs/liblttng-ust.so, not found (try using -rpath or -rpath-link)<br />/tmp/a/liblttng-ust/.libs/liblttng-ust.so: undefined reference to `exit_tracepoint'<br />/tmp/a/liblttng-ust/.libs/liblttng-ust.so: undefined reference to `__tracepoint_probe_unregister_queue_release'<br />/tmp/a/liblttng-ust/.libs/liblttng-ust.so: undefined reference to `__tracepoint_probe_register_queue_release'<br />/tmp/a/liblttng-ust/.libs/liblttng-ust.so: undefined reference to `__tracepoint_probe_prune_release_queue'<br />/tmp/a/liblttng-ust/.libs/liblttng-ust.so: undefined reference to `init_tracepoint'<br />collect2: error: ld returned 1 exit status</p>
<p>This issue is atleast occuring in 2.9.0, 2.9.1 and 2.10.0</p> LTTng - Feature #968 (Feedback): lttng-modules kernel and user callstack contexthttps://bugs.lttng.org/issues/9682015-10-25T20:14:40ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>Implementation from Francis Giraldeau reviewed and cleaned up available here:</p>
<p><a class="external" href="https://github.com/compudj/lttng-tools-dev/tree/callstack">https://github.com/compudj/lttng-tools-dev/tree/callstack</a><br /><a class="external" href="https://github.com/compudj/lttng-modules-dev/tree/callstack">https://github.com/compudj/lttng-modules-dev/tree/callstack</a></p>
<p>Documentation and tests are missing.</p> LTTng-UST - Feature #965 (New): Implement UST statedumphttps://bugs.lttng.org/issues/9652015-10-22T20:43:37ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>Initial implementation: <a class="external" href="https://github.com/compudj/lttng-ust-dev/tree/statedump-notifier">https://github.com/compudj/lttng-ust-dev/tree/statedump-notifier</a></p>
<p>Missing tests in lttng-tools for this feature before we can merge it into lttng-ust.</p> LTTng-modules - Feature #964 (New): Implement support for persistent memory buffershttps://bugs.lttng.org/issues/9642015-10-22T20:41:43ZMathieu Desnoyersmathieu.desnoyers@efficios.comLTTng-modules - Feature #963 (New): Implement user-space stack dump contexthttps://bugs.lttng.org/issues/9632015-10-22T20:41:10ZMathieu Desnoyersmathieu.desnoyers@efficios.com