LTTng bugs repository: Issueshttps://bugs.lttng.org/https://bugs.lttng.org/themes/lttng/favicon/a.ico?14249722912022-09-13T13:22:48ZLTTng bugs repository
Redmine 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 - Bug #1293 (New): Use after free in sink.ctf.fs finalizehttps://bugs.lttng.org/issues/12932020-12-02T21:27:04ZSimon Marchisimon.marchi@polymtl.ca
<p>I run this:</p>
<pre>./src/cli/babeltrace2 ~/lttng-traces/auto-20200318-221703 -c sink.ctf.fs -p 'path="/tmp/yo"'</pre>
<p>and interrupt with with ^C while it's running. I get:</p>
<pre>
➜ babeltrace ./src/cli/babeltrace2 ~/lttng-traces/auto-20200318-221703 -c sink.ctf.fs -p 'path="/tmp/yo"'
^C=================================================================
==1611811==ERROR: AddressSanitizer: heap-use-after-free on address 0x60d000001de8 at pc 0x7faa59a98c13 bp 0x7fff9f10b9b0 sp 0x7fff9f10b9a0
READ of size 8 at 0x60d000001de8 thread T0
#0 0x7faa59a98c12 in bt_trace_get_environment_entry_count /home/simark/src/babeltrace/src/lib/trace-ir/trace.c:345
#1 0x7faa5663faed in translate_trace_ctf_ir_to_tsdl /home/simark/src/babeltrace/src/plugins/ctf/fs-sink/translate-ctf-ir-to-tsdl.c:935
#2 0x7faa566496f4 in fs_sink_trace_destroy /home/simark/src/babeltrace/src/plugins/ctf/fs-sink/fs-sink-trace.c:499
#3 0x7faa598959d1 (/usr/lib/libglib-2.0.so.0+0x3c9d1)
#4 0x7faa5989663a in g_hash_table_remove_all (/usr/lib/libglib-2.0.so.0+0x3d63a)
#5 0x7faa59899d5e in g_hash_table_destroy (/usr/lib/libglib-2.0.so.0+0x40d5e)
#6 0x7faa5662a894 in destroy_fs_sink_comp /home/simark/src/babeltrace/src/plugins/ctf/fs-sink/fs-sink.c:132 #7 0x7faa5663161b in ctf_fs_sink_finalize /home/simark/src/babeltrace/src/plugins/ctf/fs-sink/fs-sink.c:1141
#8 0x7faa59a2f50b in finalize_component /home/simark/src/babeltrace/src/lib/graph/component.c:97 #9 0x7faa59a2f87a in destroy_component /home/simark/src/babeltrace/src/lib/graph/component.c:148
#10 0x7faa59a340e2 in bt_object_try_spec_release /home/simark/src/babeltrace/src/lib/object.h:145 #11 0x7faa5987765f (/usr/lib/libglib-2.0.so.0+0x1e65f)
#12 0x7faa59a34ee6 in destroy_graph /home/simark/src/babeltrace/src/lib/graph/graph.c:103
#13 0x7faa59a346af in bt_object_put_ref_no_null_check /home/simark/src/babeltrace/src/lib/object.h:307
#14 0x7faa59a34800 in bt_object_put_ref /home/simark/src/babeltrace/src/lib/object.h:335 #15 0x7faa59a3adb4 in bt_graph_put_ref /home/simark/src/babeltrace/src/lib/graph/graph.c:1331
#16 0x55e2ffb90c67 in cmd_run_ctx_destroy /home/simark/src/babeltrace/src/cli/babeltrace2.c:1685 #17 0x55e2ffb95d9e in cmd_run /home/simark/src/babeltrace/src/cli/babeltrace2.c:2538
#18 0x55e2ffb96a99 in main /home/simark/src/babeltrace/src/cli/babeltrace2.c:2673
#19 0x7faa59696151 in __libc_start_main (/usr/lib/libc.so.6+0x28151)
#20 0x55e2ffb87fdd in _start (/home/simark/build/babeltrace/src/cli/.libs/lt-babeltrace2+0x1ffdd)
0x60d000001de8 is located 104 bytes inside of 144-byte region [0x60d000001d80,0x60d000001e10)
freed by thread T0 here:
#0 0x7faa59c1c0e9 in __interceptor_free /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:123
#1 0x7faa59a97b4a in destroy_trace /home/simark/src/babeltrace/src/lib/trace-ir/trace.c:143
#2 0x7faa59a90621 in bt_object_put_ref_no_null_check /home/simark/src/babeltrace/src/lib/object.h:307
#3 0x7faa59a8ff99 in bt_object_with_parent_release_func /home/simark/src/babeltrace/src/lib/object.h:178
#4 0x7faa59a8b329 in bt_object_put_ref_no_null_check /home/simark/src/babeltrace/src/lib/object.h:307
#5 0x7faa59a8c2f1 in bt_packet_recycle /home/simark/src/babeltrace/src/lib/trace-ir/packet.c:131
#6 0x7faa59a8b329 in bt_object_put_ref_no_null_check /home/simark/src/babeltrace/src/lib/object.h:307
#7 0x7faa59a8b47a in bt_object_put_ref /home/simark/src/babeltrace/src/lib/object.h:335
#8 0x7faa59a8ccc4 in bt_packet_put_ref /home/simark/src/babeltrace/src/lib/trace-ir/packet.c:236
#9 0x7faa56643f48 in fs_sink_stream_destroy /home/simark/src/babeltrace/src/plugins/ctf/fs-sink/fs-sink-stream.c:39
#10 0x7faa598959d1 (/usr/lib/libglib-2.0.so.0+0x3c9d1)
previously allocated by thread T0 here:
#0 0x7faa59c1c639 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7faa598a9641 in g_malloc0 (/usr/lib/libglib-2.0.so.0+0x50641)
#2 0x7faa566568b8 in ctf_fs_trace_create /home/simark/src/babeltrace/src/plugins/ctf/fs-src/fs.c:1080
#3 0x7faa566572b0 in ctf_fs_component_create_ctf_fs_trace_one_path /home/simark/src/babeltrace/src/plugins/ctf/fs-src/fs.c:1183
#4 0x7faa5665be1d in ctf_fs_component_create_ctf_fs_trace /home/simark/src/babeltrace/src/plugins/ctf/fs-src/fs.c:2097
#5 0x7faa5665dff0 in ctf_fs_create /home/simark/src/babeltrace/src/plugins/ctf/fs-src/fs.c:2397
#6 0x7faa5665e172 in ctf_fs_init /home/simark/src/babeltrace/src/plugins/ctf/fs-src/fs.c:2431
#7 0x7faa59a39c15 in add_component_with_init_method_data /home/simark/src/babeltrace/src/lib/graph/graph.c:1048
#8 0x7faa59a3a2fb in add_source_component_with_initialize_method_data /home/simark/src/babeltrace/src/lib/graph/graph.c:1127
#9 0x7faa59a3a3a2 in bt_graph_add_source_component /home/simark/src/babeltrace/src/lib/graph/graph.c:1152
#10 0x55e2ffb94343 in cmd_run_ctx_create_components_from_config_components /home/simark/src/babeltrace/src/cli/babeltrace2.c:2252
#11 0x55e2ffb94ff7 in cmd_run_ctx_create_components /home/simark/src/babeltrace/src/cli/babeltrace2.c:2347
#12 0x55e2ffb95825 in cmd_run /home/simark/src/babeltrace/src/cli/babeltrace2.c:2461
#13 0x55e2ffb96a99 in main /home/simark/src/babeltrace/src/cli/babeltrace2.c:2673
#14 0x7faa59696151 in __libc_start_main (/usr/lib/libc.so.6+0x28151)
SUMMARY: AddressSanitizer: heap-use-after-free /home/simark/src/babeltrace/src/lib/trace-ir/trace.c:345 in bt_trace_get_environment_entry_count
</pre> LTTng - Bug #1192 (New): Web documentation improvement: describe use of CREATE_TRACE_POINTS for l...https://bugs.lttng.org/issues/11922019-08-05T14:36:42ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>Following discussion with David Goulet who is currently instrumenting the tor project with lttng-ust, it appears that the following use-case should be documented more clearly in the web documentation:</p>
<ul>
<li>Instrumentation of applications with LTTng-UST</li>
</ul>
<p>A tracepoint provider header should be included <em>once</em> per application within a compile unit after a #define CREATE_TRACE_POINTS.</p>
<p>It can be included multiple times throughout other compile units of the applications, but make sure the CREATE_TRACE_POINTS macro is not defined before those include, otherwise LTTng-UST will complain about multiple tracepoint probe definitions.</p> Babeltrace - Feature #1164 (New): Write a plugin to anonymize traceshttps://bugs.lttng.org/issues/11642018-05-17T16:14:29ZGeneviève Bastiengbastien+lttng@versatic.net
<p>Here's a feature that was discussed during last hack-a-thon:</p>
<p>Write a babeltrace plugin that would allow to remove all internal information from the trace, so that the trace can be sent for analysis without exposing internal information.</p>
<p>The kind of information to anonymize (not exhaustive, more thoughts need to be put in it):</p>
<ul>
<li>In the metadata: host names</li>
</ul>
<ul>
<li>IP addresses: Change them for dummy IPs</li>
</ul>
<ul>
<li>File names</li>
</ul>
<ul>
<li>Process names?</li>
</ul>
<p>The plugin should keep a mapping of the anonymized information so that results can be mapped back to original data.</p> 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-modules - Feature #1067 (New): Update writeback instrumentation for newer kernelshttps://bugs.lttng.org/issues/10672016-10-07T19:38:23ZJérémie Galarneaujeremie.galarneau@efficios.comBabeltrace - Feature #1045 (New): Wire up debug info on lttng_ust_cyg_profile event fieldshttps://bugs.lttng.org/issues/10452016-07-13T14:53:52ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>#lttng paste</p>
<p>09:56 < rnsanchez> is there a default procedure for "hydrating" instrument-functions traces like this?<br />09:56 < rnsanchez> [13:54:09.866652414] (+0.000001178) priminho lttng_ust_cyg_profile:func_exit: { cpu_id = 1 }, { addr = 0x46BB90, call_site = 0x46BF7B }<br />09:56 < rnsanchez> (kind of replacing the addr with their proper symbols)<br />09:57 < milian> rnsanchez: I'm not an lttng dev, but could imagine that one would be able to write that by analyzing mmap + openat to find the offset into a library, which you can then feed into addr2line, or libdw/libbacktrace<br />09:59 < rnsanchez> I could propably pass it (babeltrace) through some script to do that. but since the trace is huge (and this is not even a "real" trace), I was wondering if there is a better way to do that<br />09:59 < milian> I'd also be interested in that<br />10:00 < rnsanchez> well maybe there is one. building a symbol-table cache for the known things (a binary of special interest) and then feeding babeltrace through awk, replacing the symbols found with their names<br />10:01 < rnsanchez> some would miss, of course, but perhaps a good amount would help<br />10:46 < Compudj> rnsanchez, milian: currently, babeltrace is a bit "hardwired" to the "ip" context for symbol resolution<br />10:46 < Compudj> but all the infrastructure code is there<br />10:49 < Compudj> see babeltrace: formats/ctf-text/types/integer.c<br />10:49 < Compudj> there is a call to ctf_text_integer_write_debug_info<br />10:50 < Compudj> implemented in include/babeltrace/trace-debug-info.h<br />10:50 < Compudj> it checks if integer_definition->debug_info_src is non-null<br />10:51 < Compudj> this is wired up in lib/debug-info.c register_event_debug_infos()<br />10:51 < Compudj> it is where it is tied to the "ip" context<br />10:51 < Compudj> it should be extended to be tied to the lttng_ust_cyg_profile event fields too</p> LTTng-tools - Feature #986 (New): Warn when unreasonably short timer values are usedhttps://bugs.lttng.org/issues/9862016-01-05T22:35:59ZJérémie Galarneaujeremie.galarneau@efficios.com
<p>Most timer configuration options are expressed in microseconds which makes it easy for users to specify an unreasonably short intervals of time. These configuration mistakes result in unusually high tracing overhead and may be quite challenging to figure out for inexperienced users.</p>
<p>The lttng client should warn when timers are set to very low values.</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.comUserspace RCU - Feature #941 (New): URCU flavor which can be used across processes using shared m...https://bugs.lttng.org/issues/9412015-09-26T16:23:20ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>The appears to be interest for a URCU flavor which can be used across a set of processes communicating through shared memory.</p> Userspace RCU - Feature #940 (New): Wire up sys membarrier on each architecturehttps://bugs.lttng.org/issues/9402015-09-26T16:00:41ZMathieu Desnoyersmathieu.desnoyers@efficios.comLTTng-UST - Feature #483 (New): Use "man 3 backtrace" to dump the stack state at record start (at...https://bugs.lttng.org/issues/4832013-03-26T11:32:44ZPaul Woegererpaul_woegerer@mentor.com
<p>When an already running application gets traced with liblttng-ust-cyg-profile<br />function entry/exit instrumentation we should provide a way to reconstruct the<br />stack state at connection time. This can be achieved by using the backtrace<br />feature of glibc.</p>
<p>The following conversation on IRC motivated this feature request:</p>
<p>[09:51] <pwoegere> Compudj: Regarding <a class="external" href="http://git.lttng.org/?p=lttng-ust.git;a=blob;f=liblttng-ust-cyg-profile/lttng-ust-cyg-profile.c;h=d772e76b961a148d19bf04d56ae9481b697d99b5;hb=70d654f22a6b52beddfb86ec3daa453073c356d2#l39">http://git.lttng.org/?p=lttng-ust.git;a=blob;f=liblttng-ust-cyg-profile/lttng-ust-cyg-profile.c;h=d772e76b961a148d19bf04d56ae9481b697d99b5;hb=70d654f22a6b52beddfb86ec3daa453073c356d2#l39</a><br />[09:52] <pwoegere> Compudj: There is a disadvantage not to pass the return address on lttng_ust_cyg_profile:func_exit<br />[09:52] <pwoegere> Compudj: Think about the use case where you start recording in the middle of the application ...<br />[09:53] <pwoegere> Compudj: <br />[09:53] <pwoegere> All the lttng_ust_cyg_profile:func_exit events where<br />[09:53] <pwoegere> there is no corresponding func_entry (because it was emitted before the<br />[09:53] <pwoegere> attach happend) are basically worthless.<br />[09:56] <pwoegere> Compudj: If you also pass the call_site to func_exit to you will have useful func_exit events even when you don't have the corresponding func_entry<br />[11:40] <Compudj> pwoegere: yes, it's a question of trade-off<br />[11:41] <Compudj> pwoegere: is it worth it to almost double the size of the traces (and thus double the throughput needed) in order to handle the few func_exit events that would happen to be there at trace start without matching func_entry ?<br />[11:41] <Compudj> pwoegere: in my opinion, the saving in trace bandwidth is far more important<br />[12:20] <pwoegere> Compudj: We could use something like "man 3 backtrace" to dump the stack state at record start (attach) time. This would allow to reconstruct the missed stack state.<br />[12:24] <Compudj> pwoegere: it sounds like an excellent idea!<br />[12:24] <Compudj> pwoegere: could you open a feature request on bugs.lttng.org along with this reference ?</p>