LTTng bugs repository: Issueshttps://bugs.lttng.org/https://bugs.lttng.org/themes/lttng/favicon/a.ico?14249722912017-06-02T01:36:05ZLTTng bugs repository
Redmine LTTng-tools - Bug #1117 (New): lttng-relayd should use specific major.minor versions for relay-co...https://bugs.lttng.org/issues/11172017-06-02T01:36:05ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>Currently, it uses RELAYD_VERSION_COMM_MAJOR/MINOR, which are increased at each LTTng minor release, and therefore automatically bump the minor version even though there are no new features added.</p> LTTng-tools - Bug #1116 (New): MI XSD minor version should have been bumped once or twice (?) bet...https://bugs.lttng.org/issues/11162017-06-02T00:42:28ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>Looking at the diff of the xsd, we see that its content changed, which should have required minor xsd version bumps. What should we do now ?</p> LTTng-tools - Bug #1115 (New): LTTng sessiond should accept different agent minor version numberhttps://bugs.lttng.org/issues/11152017-06-02T00:40:03ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>Currently, it refuses to talk to agents with different minor number, which would not allow compatibility between minor bumps (feature addition).</p>
<p>Given that the agents only sent their major/minor version (and sessiond do not send its own), we should only accept agent minor versions that are <= to the server minor version.</p>
<p>If we ever want to support letting the sessiond talk to agents with higher minor version number, we should change the protocol to allow the agent handling component in the sessiond to publish its own minor version number to the application agents, so they would know they should only use a subset of their feature set.</p> LTTng-modules - Feature #1061 (New): New btrfs events should be added to lttng-modules instrument...https://bugs.lttng.org/issues/10612016-08-30T21:23:10ZMathieu Desnoyersmathieu.desnoyers@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-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.comLTTng-modules - Feature #962 (New): add x86 exceptions.h and irq_vectors.h instrumentation (and m...https://bugs.lttng.org/issues/9622015-10-22T19:47:19ZMathieu 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 #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 #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>