LTTng bugs repository: Issueshttps://bugs.lttng.org/https://bugs.lttng.org/themes/lttng/favicon/a.ico?14249722912023-10-26T19:32:57ZLTTng bugs repository
Redmine LTTng-UST - Bug #1398 (New): reserved identifier violationhttps://bugs.lttng.org/issues/13982023-10-26T19:32:57ZMarkus Elfring
<p>I would like to point out that some identifiers do eventually not fit to the expected naming convention of the C language standard.<br /><a class="external" href="https://www.securecoding.cert.org/confluence/display/c/DCL37-C.+Do+not+declare+or+define+a+reserved+identifier">https://www.securecoding.cert.org/confluence/display/c/DCL37-C.+Do+not+declare+or+define+a+reserved+identifier</a></p>
<p>Would you like to adjust your selection for unique names?</p>
Examples:
<ul>
<li>_UST_COMMON_CLOCK_H<br /> <a class="external" href="https://github.com/lttng/lttng-ust/blob/8bc1125eb851b2c52d3263c2992e6806017e98e7/src/common/clock.h#L7-L8">https://github.com/lttng/lttng-ust/blob/8bc1125eb851b2c52d3263c2992e6806017e98e7/src/common/clock.h#L7-L8</a></li>
<li>__lttng_ust_siov<br /> <a class="external" href="https://github.com/lttng/lttng-ust/blob/8bc1125eb851b2c52d3263c2992e6806017e98e7/src/common/snprintf/fvwrite.h#L18">https://github.com/lttng/lttng-ust/blob/8bc1125eb851b2c52d3263c2992e6806017e98e7/src/common/snprintf/fvwrite.h#L18</a></li>
</ul> Userspace RCU - Bug #1396 (New): reserved identifier violationhttps://bugs.lttng.org/issues/13962023-10-26T15:17:27ZMarkus Elfring
<p>I would like to point out that a few identifiers do eventually not fit to the expected naming convention of the C language standard.<br /><a class="external" href="https://www.securecoding.cert.org/confluence/display/c/DCL37-C.+Do+not+declare+or+define+a+reserved+identifier">https://www.securecoding.cert.org/confluence/display/c/DCL37-C.+Do+not+declare+or+define+a+reserved+identifier</a></p>
<p>Would you like to adjust your selection for unique names?</p>
Examples:
<ul>
<li>_URCU_WAIT_H<br /> <a class="external" href="https://github.com/urcu/userspace-rcu/blob/008a71ef213f23c8d403e086563155121b286c0c/src/urcu-wait.h#L5">https://github.com/urcu/userspace-rcu/blob/008a71ef213f23c8d403e086563155121b286c0c/src/urcu-wait.h#L5</a></li>
<li>__cds_wfcq_init<br /> <a class="external" href="https://github.com/urcu/userspace-rcu/blob/008a71ef213f23c8d403e086563155121b286c0c/include/urcu/wfcqueue.h#L136">https://github.com/urcu/userspace-rcu/blob/008a71ef213f23c8d403e086563155121b286c0c/include/urcu/wfcqueue.h#L136</a></li>
</ul> Userspace RCU - Feature #1368 (New): Integrate RCU implementation from libside into liburcuhttps://bugs.lttng.org/issues/13682023-02-14T14:26:10ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>libside features a multi-domain RCU implementation semantically similar to the Linux kernel's SRCU's implementation. It tracks grace periods with per-cpu counters rather than per-thread state.</p>
<p><a class="external" href="https://github.com/efficios/libside/blob/master/src/rcu.h">https://github.com/efficios/libside/blob/master/src/rcu.h</a><br /><a class="external" href="https://github.com/efficios/libside/blob/master/src/rcu.c">https://github.com/efficios/libside/blob/master/src/rcu.c</a></p>
<p>It is somewhat different from other urcu flavors because it supports multiple domains, whereas current liburcu flavors only have a single domain per process.</p>
<p>We would have to think thoroughly about the impacts of supporting multiple domains on other parts of liburcu such as the call_rcu worker thread. The worker thread would either have to be able to synchronize with multiple RCU domains, or we would have to require each worker thread to be associated with a single RCU domain.</p>
<p>Similar concerns arise with respect to data structures such as rculfhash which take a urcu flavor as parameter: with per-domain flavor, those would have to be associated with a specific RCU domain in addition to the flavor.</p> LTTng-UST - Bug #1242 (Feedback): SEGV on process exit with shared libraryhttps://bugs.lttng.org/issues/12422020-03-05T00:35:47ZStephen Hemminger
<p>Our application has a main process and a dynamically loaded library.<br />Both are using Lttng userspace tracepoints.</p>
<p>On process exit (initiated by ctrl-C) the main process does its cleanup and calls dlclose() on the dynamic libary.<br />That part is handled normally.</p>
<p>The issue is that later the main process gets a SEGV in the lttng-ust library cleanup logic.<br />Does the lttng internals still have references to the unloaded memory.</p>
<p>[Switching to Thread 0xfffff722b010 (LWP 18895)]<br />0x0000fffff7ea3b1c in ?? () from /lib/liblttng-ust.so.0<br />(gdb) where<br />#0 0x0000fffff7ea3b1c in ?? () from /lib/liblttng-ust.so.0<br />#1 0x0000fffff7fdcb1c in <em>dl_fini () at dl-fini.c:138<br />#2 0x0000fffff79e12d0 in __run_exit_handlers (status=0, listp=0xfffff7b125c8 <</em>_exit_funcs>, <br /> run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:108<br />#3 0x0000fffff79e1434 in __GI_exit (status=<optimized out>) at exit.c:139<br />#4 0x0000fffff79cdce8 in __libc_start_main (main=0xaaaaaaab2a60 <main>, argc=3, argv=0xfffffffffbf8, init=<optimized out>, <br /> fini=<optimized out>, rtld_fini=<optimized out>, stack_end=<optimized out>) at ../csu/libc-start.c:342<br />#5 0x0000aaaaaaab336c in _start () at ../sysdeps/aarch64/start.S:94<br />Backtrace stopped: previous frame identical to this frame (corrupt stack?)<br />(gdb) q<br />A debugging session is active.</p>
<pre><code>Inferior 1 [process 18895] will be killed.</code></pre> LTTng-UST - Bug #1203 (New): Improve documentation of lttng-ust with daemonshttps://bugs.lttng.org/issues/12032019-10-07T15:51:26ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>The lttng-ust(3) man page should be clarified regarding the scenarios where the liblttng-ust-fork.so wrapper is needed.</p>
<p>It should document that it is needed in scenarios where applications using fork(2), clone(2) (with CLONE_VM flag cleared), BSD's rfork(2), daemon(3), without <strong>immediately</strong> following those by an exec(3) family call. This includes scenarios where close(2) is used to close file descriptors before invoking exec(3), even though close(2) is listed as an async-signal-safe function.</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-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> Userspace 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 #710 (New): List event fields in the same order as the TP definitionhttps://bugs.lttng.org/issues/7102014-01-09T15:37:19ZDavid Goulet
<p>Considering this tracepoint definition taken from tests/hello/</p>
<pre>
TRACEPOINT_EVENT(ust_tests_hello, tptest,
TP_ARGS(int, anint, int, netint, long *, values,
char *, text, size_t, textlen,
double, doublearg, float, floatarg,
bool, boolarg),
TP_FIELDS(
ctf_integer(int, intfield, anint)
ctf_integer_hex(int, intfield2, anint)
ctf_integer(long, longfield, anint)
ctf_integer_network(int, netintfield, netint)
ctf_integer_network_hex(int, netintfieldhex, netint)
ctf_array(long, arrfield1, values, 3)
ctf_array_text(char, arrfield2, text, 10)
ctf_sequence(char, seqfield1, text,
size_t, textlen)
ctf_sequence_text(char, seqfield2, text,
size_t, textlen)
ctf_string(stringfield, text)
ctf_float(float, floatfield, floatarg)
ctf_float(double, doublefield, doublearg)
ctf_integer(bool, boolfield, boolarg)
ctf_integer_nowrite(int, filterfield, anint)
)
)
</pre>
<p>When listing fields with ustctl_tracepoint_field_list() and ustctl_tracepoint_field_list_get() (using for instance lttng list -u -f), the fields<br />are sent back in the reverse order starting at the bottom of TP_FIELDS().</p>
<pre>
ust_tests_hello:tptest (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint)
field: filterfield (integer) [no write]
field: boolfield (integer)
field: doublefield (float)
field: floatfield (float)
field: stringfield (string)
field: seqfield2 (string)
field: seqfield1 (unknown)
field: arrfield2 (string)
field: arrfield1 (unknown)
field: netintfieldhex (integer)
field: netintfield (integer)
field: longfield (integer)
field: intfield2 (integer)
field: intfield (integer)
</pre>
<p>No idea if it's stored in a list or in a hashtable but if possible having them listed in the same order could nice.</p> LTTng-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> LTTng-UST - Feature #447 (New): Support dlopen/dlclose of probe providershttps://bugs.lttng.org/issues/4472013-02-15T13:01:48ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>Since lttng-ust 2.1, the glibc deadlocks documented within lttng-ust(3) manpage have been worked-around with a "tls fixup" within constructor trick. However, it is still not safe to use dlclose on a provider shared object that is being actively used for tracing due to lack of reference counting from lttng-ust to the used shared object. This leads to either:</p>
<p>- segmentation fault while tracing, since events could use a serialization function located within an unloaded shared object.<br />- segmentation fault while destroying trace session or exiting process, trying to access the event description located within unloaded shared object.<br />- segmentation fault while dumping metadata for a trace session, since it would be trying to access event description located within unloaded .so.</p>
<p>Since we don't want to mess with metadata description nor synchronization of tracing while unloading a module, the best solution I can think of (and the solution that is the most similar to the approach taken with lttng-modules for kernel tracing) is to hold a reference count on the provider .so when it's used by a tracing session. One way to do this would be to use dladdr() to lookup the library path, and use a pair of dlopen()/dlclose() at tracing session creation/destruction within lttng-ust to take an extra reference count on each shared object used.</p> LTTng-UST - Feature #446 (New): Improve process startup time with many eventshttps://bugs.lttng.org/issues/4462013-02-15T12:54:19ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>J9 VM instrumentation has 16k individual events. Latest UST changes improves the process startup time from about 180s down to 2-4s (depending if tracing is active or not). However, this is still far from the 200ms process startup time normally expected for J9 VM.</p>
<p>There are a couple of ways to improve things:</p>
<p>a) implement a pre-computed hash table and or radix tree within the probe provider. Given the tracepoint names within a provider are known statically, we could construct a data structure to access them efficiently after object compilation, generate C code to construct those structures, and generate an output object, which would be linked with the provider object to create the shared library. The hash table would fit for use-cases where events are enabled by name, and radix tree (or something similar) would be better suited for wildcards.</p>
<p>b) a simpler solution for the disabled tracing case might be to delay addition of tracepoints to the hash table until the moment this data structure is actually needed (lazy initialization).</p> LTTng-UST - Feature #440 (New): Tracepoint Documentationhttps://bugs.lttng.org/issues/4402013-02-11T19:11:15ZMatthew Khouzam
<p>It would be good to have an optional macro to document tracepoints such as "TRACEPOINT_DOCUMENT(provider, name, "MESSAGE");" this way people within the same organisation can query tracepoints and better understand if they should activate one or not.</p> LTTng-UST - Feature #327 (On pause): Implement missing hostname contexthttps://bugs.lttng.org/issues/3272012-08-26T23:22:47ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>To match features of lttng-modules.</p>