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 #1320 (Feedback): Assert in lttng-ring-buffer-client.h:437: client_buffer_begin()https://bugs.lttng.org/issues/13202021-07-14T00:33:40ZSergei Dyshel
<p>We observed single case where process instrumented with LTTNG crashed on start with the following assert:<br />```<br />#0 0x00007f361008b495 in raise () from /lib64/libc.so.6<br />#1 0x00007f361008cc75 in abort () from /lib64/libc.so.6<br />#2 0x00007f361008460e in __assert_fail_base () from /lib64/libc.so.6<br />#3 0x00007f36100846d0 in __assert_fail () from /lib64/libc.so.6<br />#4 0x00007f361127c349 in client_buffer_begin (buf=0x7f35fbee7000, tsc=141244066318, subbuf_idx=0, handle=0x7f36080008c0) at lttng-ring-buffer-client.h:437<br />#5 0x00007f361128e5a0 in lib_ring_buffer_switch_old_start (buf=0x7f35fbee7000, chan=0x7f3608010a40, tsc=141244066318, handle=0x7f36080008c0, offsets=<optimized out>) at ring_buffer_frontend.c:1775<br />#6 0x00007f361128eb7c in lib_ring_buffer_reserve_slow (ctx=ctx@entry=0x7ffee79ab120, client_ctx=client_ctx@entry=0x7ffee79aadf0) at ring_buffer_frontend.c:2385<br /><a class="issue tracker-1 status-5 priority-5 priority-high2 closed" title="Bug: Double PID registering and unregistering race (Resolved)" href="https://bugs.lttng.org/issues/7">#7</a> 0x00007f361127fd4f in lib_ring_buffer_reserve (config=0x7f36112b0da0 <client_config>, client_ctx=0x7ffee79aadf0, ctx=0x7ffee79ab120) at ../libringbuffer/frontend_api.h:212<br />#8 lttng_event_reserve (ctx=<optimized out>, event_id=<optimized out>) at lttng-ring-buffer-client.h:760<br />```</p>
<p>LTTNG version: 2.12.2<br />Session parameters:<br />```<br />lttng create XXX --live<br />lttng enable-channel channel0 -u -s XXX --subbuf-size 1M --num-subbuf 8 --overwrite --tracefile-size 104857600 --tracefile-count 3<br />lttng enable-event 'XXX_*' -u -s XXX -c channel0<br />lttng add-context -u -t vpid -t vtid -s XXX -c channel0<br />lttng start XXX<br />```</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 #1285 (Feedback): about close file failed for lttng-ust modulehttps://bugs.lttng.org/issues/12852020-10-10T09:52:42Zkun song
<p>Hi,all</p>
<p>I found some relative modification for lttng-ust.<br />commit<br />20d1999d42392063fd530d1f6c00b93c25d178d6<br />793d29c9367a58c2a368bc1ccb11b01c2d2bdac2<br />48a143c09cc97bf7a2ace811277e7d60b294b5f6<br />96a6162e1925d4bd1dfc6f4167d75f396c0dbe4c<br />283f4bec47781f7a39dde82d02e53add02155f9c<br />c1be081a2f016fb6dcaef1d471389ede3aa00103<br />5a4d96d170a38f29bf147b84e248a47d45ee7d8e<br />7d34f27dce903a88241e96787c1f900b6ea08245<br />ba8dcc8ca5b8b7bebed4e10b3dd4fcbc783d529d</p>
<p>Test step<br />LD_PRELOAD=lttng-ust-fork.so dpdk-devbind.py -s<br />When exec command,close file failed.</p>
<p>#1 0x00007f31b9705524 in __GI_abort () at abort.c:79</p>
<p>[**ALERT: The abort() might not be exactly invoked from the following function line.<br />If the trail function contains multiple abort() calls, then you should cross check by other means to get correct abort() call location.<br />This is due to the optimized compilation which hides the debug info for multiple abort() calls in a given function.<br />Refer TR HU16995 for more information]<br />#2 0x00007f31b970540f in _<em>assert_fail_base (fmt=0x7f31b9862ec8<br />"%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7f31b96bbcdd "0", file=0x7f31b96c4cd0 <del>Type <RET> for more, q to quit, c to continue without paging</del> "../../git/libringbuffer/shm.c", line=427, function=<optimized out>) at<br />assert.c:92<br />#3 0x00007f31b97127d2 in _GI</em>_assert_fail (assertion=assertion@entry =0x7f31b96bbcdd "0", file=file@entry=0x7f31b96c4cd0 "../../git/libringbuffer/shm.c", line=line@entry=427,<br />function=function@entry=0x7f31b96c4dc0 <_PRETTY_FUNCTION_.4744><br />"shmp_object_destroy") at assert.c:101<br />#4 0x00007f31b96b3f1d in shmp_object_destroy (obj=obj@entry=0x7f31b401 1740, consumer=consumer@entry=0) at ../../git/libringbuffer/shm.c:427<br />#5 0x00007f31b96b4d4f in shm_object_table_destroy (table=0x7f31b4011730, consumer=consumer@entry=0) at<br />../../git/libringbuffer/shm.c:451<br />#6 0x00007f31b96b034d in channel_free (consumer=0, handle=0x7f31b4012f10, chan=0x7f31b4011170) at<br />../../git/libringbuffer/ring_buffer_frontend.c:926<br /><a class="issue tracker-1 status-5 priority-5 priority-high2 closed" title="Bug: Double PID registering and unregistering race (Resolved)" href="https://bugs.lttng.org/issues/7">#7</a> channel_release (consumer=0, handle=0x7f31b4012f10,<br />chan=0x7f31b4011170) at<br />../../git/libringbuffer/ring_buffer_frontend.c:1129<br />#8 channel_destroy (chan=0x7f31b4011170, handle=0x7f31b4012f10,<br />consumer=consumer@entry=0) at</p>
<p>../../git/libringbuffer/ring_buffer_frontend.c:1161</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 #1100 (New): Add (possibly symbolic) event whenever blocking occurs due to ex...https://bugs.lttng.org/issues/11002017-05-08T17:24:36ZRicardo Nabinger Sanchezrnsanchez@gmail.com
<p>When using <code>LTTNG_UST_BLOCKING_RETRY_TIMEOUT</code>, it is desirable to know when blocking occured. This way an analyst will stay informed of periods in the trace where precision of events had to be traded for completeness.</p>
<p>This has been discussed informally in the IRC channel:<br /><pre>
[09:08:06] rnsanchez such points could be of interest in my analysis :+)
[09:59:35] Compudj rnsanchez: no
[10:01:19] Compudj rnsanchez: but looking at event clusters in your trace will help
[10:01:36] rnsanchez Compudj: what about throwing a single/occasional event for a corresponding tid/pid that was ungraced due to excessive events?
[10:01:56] Compudj rnsanchez: with multi-session support, that would not be that easy
[10:02:04] Compudj we'd have to know which buffers are affected
[10:02:22] Compudj so we don't generate noise into other sessions
[10:02:36] rnsanchez I see
[10:02:37] rnsanchez sounds fair
[10:03:35] Compudj rnsanchez: if we add such info eventually, I'd be tempted to add a packet header field for that
[10:03:47] Compudj which could counts the "blocking" a buffer has had so far
[10:04:11] Compudj so we don't rely on events to relay information that is transport-level
[10:04:35] Compudj that would be doable (you may want to add a feature request on bugs.lttng.org)
[10:05:26] rnsanchez well that kind of info could be "rendered" into tools such as Trace Compass. it would be informative enough for the analyst to take a convolute period with a grain/spoon of salt
[10:05:57] rnsanchez Compudj: I can do that, sure
[10:06:04] Compudj rnsanchez: yes, and having those counters in the packet header would nicely match the spots where the situation occurs
[10:06:15] Compudj blocking always happen at sub-buffer (packet) boundary
[10:09:06] rnsanchez so it would act (briefly) as a relaxed clock? i.e., "between events En and En+1, we blocked, take that into account"
[10:09:24] rnsanchez (relaxed as in not actually probing clocks for a timestamp)
[10:10:43] Compudj yes, if we detect that the blocking counter increased between two consecutive packets, we can put a marker between timestamp end of the first packet and timestamp begin of the second packet saying that the source has been blocked during that time
[10:11:11] rnsanchez perfect
[10:12:19] Compudj you may want to paste this conversation into the bug tracker feature request, it will make it easier to remember the details when/if we get to implement it
[10:13:26] rnsanchez doing that as we speak
</pre></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 #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>