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 #1294 (New): add-context fails silently with perf_event_paranoid=4, no trace prod...https://bugs.lttng.org/issues/12942020-12-02T23:45:38ZJeff Trull
<p>Desired result:<br />A disallowed add-context (e.g. because of perf_event_paranoid) produces an error message and a non-zero exit code.</p>
<p>Actual result:<br />A disallowed add-context produces only a message in the system log, invisible to the normal user.<br />For example, when perf_event_paranoid forbids it you get a message of the form:</p>
<p><code>Error: UST app create channel context failed for app (pid: 76220) with ret -1024</code></p>
<p>But the only effects observable to the user are:</p>
<ol>
<li>no trace is produced, and</li>
<li>when you destroy the session there is a message like <code>Failed to perform a quiet rotation as part of the destruction of session "..."</code></li>
</ol>
<p>If other users are like me they will spend quite some time trying to figure out what is wrong in their code, setup etc. before figuring out what's wrong (or having someone on IRC identify it for them, as in my case).</p>
<p>This is Ubuntu 20.04.1, with lttng-ust 2.11.0</p> 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> 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 #717 (New): Better validation of tracepoint provider headers?https://bugs.lttng.org/issues/7172014-01-15T17:35:27ZDaniel U. Thibaultdaniel.thibault@drdc-rddc.gc.ca
<p>I fooled around to try and break the LTTng tracepoint provider preparation process at the level of the event field names. Turns out the literals supplied to the <code>ctf_*</code> macros as arguments for <code>TP_FIELDS</code> are pretty robust. Maybe too robust.</p>
<p>If you supply a non-identifier (see ISO/IEC 9899:TC2 (9899:1999) at 6.4.2 and Annex D) such as for instance "<code>named name</code>" or "<code>.name</code>", the tracepoint provider header compiles, links and packages into an <code>.so</code> without a hitch. The instrumented application likewise. Tracing also works flawlessly, producing a trace on disk. But when <code>babeltrace</code> tries to read it, it complains and gives up, with messages like:</p>
<pre>
[error] at line 110: token "name": syntax error, unexpected IDENTIFIER, expecting SEMICOLON or COMMA
[...]
</pre>
<p>(for "<code>named name</code>") or</p>
<pre>
[error] at line 110: token ".": syntax error, unexpected DOT, expecting SEMICOLON or COMMA
[...]
</pre>
<p>(for "<code>.name</code>")</p>
<p>There isn't much that can be done to prevent this. I would recommend merely amending the tracepoint provider samples slightly, like this:</p>
<pre>
/*
* The ctf_string macro takes a C string and writes it into a field
* named "message" (any C identifier will do for the field name)
*/
ctf_string(message, text)
</pre> LTTng-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 #602 (New): Add session to metadata environmenthttps://bugs.lttng.org/issues/6022013-07-24T18:36:42ZYannick Brosseauyannick.brosseau@polymtl.ca
<p>To aid in identifying the trace, we should add the session in the metadata (in the environment section)</p> LTTng-UST - Feature #527 (New): Add git version information to project versionhttps://bugs.lttng.org/issues/5272013-05-10T12:54:46ZMathieu Desnoyersmathieu.desnoyers@efficios.comLTTng-UST - Feature #520 (New): Allow override of /var/run directoryhttps://bugs.lttng.org/issues/5202013-05-04T13:59:36ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>Allow override of /var/run directory, as will as per-user $HOME/.lttng/ directory at configure time, and by environment variables. This should match a similar feature in lttng-tools.</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>