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 #1109 (Feedback): Fork() test 9 from Linux Test Project fails when traced with us...https://bugs.lttng.org/issues/11092017-05-23T00:00:56ZRicardo Nabinger Sanchezrnsanchez@gmail.com
<p>While tracing <a href="https://github.com/linux-test-project/ltp/tree/master/testcases/kernel/syscalls/fork" class="external"><code>fork09</code></a> test from <a href="https://github.com/linux-test-project/ltp" class="external">LTP</a>, the test failed unexpectedly. LTTng required some of the FDs the test aims at exhausting. It seems such a test will always fail when tracing, for it assumes it will be the sole user of its FD space.</p>
<p>LTTng-ust master as of <a class="changeset" title="Fix: Quote CMAKE variable assignment in Makefile Signed-off-by: Michael Jeanson <mjeanson@effici..." href="https://bugs.lttng.org/projects/lttng-ust/repository/lttng-ust/revisions/dd77bd5b20e95fefa8d857fdd3b7c9bdbbf24bc7">dd77bd5b20e95fefa8d857fdd3b7c9bdbbf24bc7</a>.</p>
<p>Steps to reproduce:<br /><pre>
git clone https://github.com/linux-test-project/ltp.git
cd ltp
make autotools
./configure
make
</pre></p>
<p>Then, when running as root, the test will abort if the problem is triggered:<br /><pre>
lttng create
lttng enable-channel -u chan_ust
lttng enable-channel -k chan_kernel
lttng add-context -u -t vpid -t ip -t procname -t vtid -c chan_ust
lttng enable-event -u -a -c chan_ust
lttng enable-event -k -c chan_kernel --syscall --all
lttng start
LD_PRELOAD=liblttng-ust-dl.so:liblttng-ust-fork.so:liblttng-ust-fd.so ./fork09
</pre></p>
<p>Example output:<br /><pre>
ltp/testcases/kernel/syscalls/fork# LD_PRELOAD=liblttng-ust-dl.so:liblttng-ust-fork.so:liblttng-ust-fd.so ./fork09
fork09 0 TINFO : OPEN_MAX is 1024
fork09 0 TINFO : first file descriptor is 22
fork09 0 TINFO : Parent reporting 1023 files open
fork09 0 TINFO : Child opened new file #1023
libgcc_s.so.1 must be installed for pthread_cancel to work
fork09 1 TBROK : tst_sig.c:233: unexpected signal SIGIOT/SIGABRT(6) received (pid = 2568).
fork09 2 TBROK : tst_sig.c:233: Remaining cases broken
fork09 0 TWARN : tst_tmpdir.c:337: tst_rmdir: rmobj(/tmp/forz9gzhZ) failed: unlink(/tmp/forz9gzhZ) failed; errno=21: EISDIR
fork09 1 TFAIL : fork09.c:147: test 1 FAILED
</pre></p>
<p>When checking the trace, one can see that some calls to <code>open()</code> failed with <code>errno == 24</code>, "Too many open files":<br /><pre>
...
[13:46:47.130018542] (+0.000013569) rns syscall_entry_open: { cpu_id = 1 }, { filename = "/etc/ld.so.cache", flags = 524288, mode = 1 }
[13:46:47.130020273] (+0.000001731) rns syscall_exit_open: { cpu_id = 1 }, { ret = -24 }
[13:46:47.130021801] (+0.000001528) rns syscall_entry_open: { cpu_id = 1 }, { filename = "/lib64/tls/x86_64/libgcc_s.so.1", flags = 524288, mode = 55440 }
[13:46:47.130022801] (+0.000001000) rns syscall_exit_open: { cpu_id = 1 }, { ret = -24 }
[13:46:47.130023703] (+0.000000902) rns syscall_entry_newstat: { cpu_id = 1 }, { filename = "/lib64/tls/x86_64" }
[13:46:47.130026945] (+0.000003242) rns syscall_exit_newstat: { cpu_id = 1 }, { ret = -2, statbuf = 140723106378272 }
[13:46:47.130027652] (+0.000000707) rns syscall_entry_open: { cpu_id = 1 }, { filename = "/lib64/tls/libgcc_s.so.1", flags = 524288, mode = 55440 }
[13:46:47.130028567] (+0.000000915) rns syscall_exit_open: { cpu_id = 1 }, { ret = -24 }
[13:46:47.130028952] (+0.000000385) rns syscall_entry_newstat: { cpu_id = 1 }, { filename = "/lib64/tls" }
[13:46:47.130030619] (+0.000001667) rns syscall_exit_newstat: { cpu_id = 1 }, { ret = -2, statbuf = 140723106378272 }
[13:46:47.130031155] (+0.000000536) rns syscall_entry_open: { cpu_id = 1 }, { filename = "/lib64/x86_64/libgcc_s.so.1", flags = 524288, mode = 55440 }
[13:46:47.130032002] (+0.000000847) rns syscall_exit_open: { cpu_id = 1 }, { ret = -24 }
[13:46:47.130032395] (+0.000000393) rns syscall_entry_newstat: { cpu_id = 1 }, { filename = "/lib64/x86_64" }
[13:46:47.130034017] (+0.000001622) rns syscall_exit_newstat: { cpu_id = 1 }, { ret = -2, statbuf = 140723106378272 }
[13:46:47.130034583] (+0.000000566) rns syscall_entry_open: { cpu_id = 1 }, { filename = "/lib64/libgcc_s.so.1", flags = 524288, mode = 55440 }
[13:46:47.130035432] (+0.000000849) rns syscall_exit_open: { cpu_id = 1 }, { ret = -24 }
[13:46:47.130035793] (+0.000000361) rns syscall_entry_newstat: { cpu_id = 1 }, { filename = "/lib64" }
[13:46:47.130039354] (+0.000003561) rns syscall_exit_newstat: { cpu_id = 1 }, { ret = 0, statbuf = 140723106378272 }
[13:46:47.130045019] (+0.000005665) rns syscall_entry_open: { cpu_id = 1 }, { filename = "/dev/tty", flags = 2306, mode = 0 }
[13:46:47.130046134] (+0.000001115) rns syscall_exit_open: { cpu_id = 1 }, { ret = -24 }
[13:46:47.130046973] (+0.000000839) rns syscall_entry_writev: { cpu_id = 1 }, { fd = 2, vec = 140723106380368, vlen = 1 }
[13:46:47.130060399] (+0.000013426) rns syscall_exit_writev: { cpu_id = 1 }, { ret = 59, vec = 140723106380368 }
[13:46:47.130061293] (+0.000000894) rns syscall_entry_mmap: { cpu_id = 1 }, { addr = 0x0, len = 4096, prot = 3, flags = 34, fd = -1, offset = 0 }
[13:46:47.130067022] (+0.000005729) rns syscall_exit_mmap: { cpu_id = 1 }, { ret = 0x7FB33758B000 }
[13:46:47.130075155] (+0.000008133) rns syscall_entry_rt_sigprocmask: { cpu_id = 1 }, { how = 1, nset = 140723106380064, sigsetsize = 8 }
[13:46:47.130075728] (+0.000000573) rns syscall_exit_rt_sigprocmask: { cpu_id = 1 }, { ret = 0, oset = 0 }
[13:46:47.130126316] (+0.000050588) rns syscall_entry_rt_sigprocmask: { cpu_id = 1 }, { how = 0, nset = 140723106379920, sigsetsize = 8 }
[13:46:47.130128042] (+0.000001726) rns syscall_exit_rt_sigprocmask: { cpu_id = 1 }, { ret = 0, oset = 140723106379792 }
[13:46:47.130128816] (+0.000000774) rns syscall_entry_getpid: { cpu_id = 1 }, { }
[13:46:47.130129698] (+0.000000882) rns syscall_exit_getpid: { cpu_id = 1 }, { ret = 2568 }
[13:46:47.130130243] (+0.000000545) rns syscall_entry_gettid: { cpu_id = 1 }, { }
[13:46:47.130131252] (+0.000001009) rns syscall_exit_gettid: { cpu_id = 1 }, { ret = 2568 }
[13:46:47.130132261] (+0.000001009) rns syscall_entry_tgkill: { cpu_id = 1 }, { tgid = 2568, pid = 2568, sig = 6 }
</pre></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 - Bug #525 (Confirmed): new "notifications" from UST do not strictly respect LTTNG_UST_...https://bugs.lttng.org/issues/5252013-05-07T15:25:54ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>We should eventually find a way to improve notifications from UST to sessiond so they don't delay .so loading (and thus application startup) when env. var. specify a LTTNG_UST_REGISTER_TIMEOUT=0. Currently, we work around this issue by setting the notification socket with a timeout of 100ms as minimum timeout if the LTTNG_UST_REGISTER_TIMEOUT value is below 100.</p>
<p>A cleaner fix could involve handling these notifications from a (possibly new) separate thread, and use a semaphore-based scheme to handle optional wait from the application.</p> LTTng-UST - Feature #508 (Feedback): arrays of floats are stored and/or displayed as arrays of intshttps://bugs.lttng.org/issues/5082013-04-19T20:33:41ZSébastien Barthélémybarthelemy@crans.org
<p>The attached patch modifies the hello.cxx test (from lttng-ust 2.1.1) to add an array of floats argument.<br />as you see in the following output (babeltrace v1.0.3 with the python bindings patchs), the field floatarrfield shows ints instead of the expected floats:</p>
<pre>
$ rm -rf ~/lttng-traces/ ; lttng create && lttng enable-event -a -u && lttng start && ./run && lttng stop && lttng destroy && babeltrace ~/lttng-traces | head -n 2
Session auto-20130419-222314 created.
Traces will be written in /home/sbarthelemy/lttng-traces/auto-20130419-222314
All UST events are enabled in channel channel0
Tracing started for session auto-20130419-222314
Hello, World!
Tracing... done.
Waiting for data availability
Tracing stopped for session auto-20130419-222314
Session auto-20130419-222314 destroyed
[22:23:14.605465399] (+?.?????????) ald-0987-de:hello:30232 ust_tests_hello:tptest: { cpu_id = 5 }, { intfield = 0, intfield2 = 0x0, longfield = 0, netintfield = 0, netintfieldhex = 0x0, arrfield1 = [ [0] = 1, [1] = 2, [2] = 3 ], arrfield2 = "test", _seqfield1_length = 4, seqfield1 = [ [0] = 116, [1] = 101, [2] = 115, [3] = 116 ], _seqfield2_length = 4, seqfield2 = "test", stringfield = "test", floatfield = 2222.1, doublefield = 2.1, floatarrfield = [ [0] = 1066192077, [1] = 1074580685, [2] = 1079194419 ] }
[22:23:14.605470207] (+0.000004808) ald-0987-de:hello:30232 ust_tests_hello:tptest: { cpu_id = 5 }, { intfield = 1, intfield2 = 0x1, longfield = 1, netintfield = 1, netintfieldhex = 0x1, arrfield1 = [ [0] = 1, [1] = 2, [2] = 3 ], arrfield2 = "test", _seqfield1_length = 4, seqfield1 = [ [0] = 116, [1] = 101, [2] = 115, [3] = 116 ], _seqfield2_length = 4, seqfield2 = "test", stringfield = "test", floatfield = 2222.1, doublefield = 2.1, floatarrfield = [ [0] = 1066192077, [1] = 1074580685, [2] = 1079194419 ] }
</pre>
<p>as a workaround, the floating point value can be retrieved in python using:<br /><pre>
In [1]: import struct
In [2]: struct.unpack('f', struct.pack('i', 1066192077))
Out[2]: (1.100000023841858,)
</pre></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> LTTng-UST - Bug #292 (Confirmed): Generated header files should not conflict with ust or standard...https://bugs.lttng.org/issues/2922012-07-03T18:27:18ZMatthew Khouzam
<p>In Lttng-UST 2.0 if a given tracepoint file (foo.tp) has tracepint_events with domains that are not "foo" the tracepoint will not compile. This would be good to have a warning/error for, since if you don't it will just cause errors in the compilation phase which are <em>very</em> difficult to understand.</p>