You need to define your concept of operations carefully. An instrumented application can include its tracepoint provider in several ways.
One is static inclusion: the application will always be traceable, but any change to the tracepoints requires a recompilation of the app, plus the tracepoint events it produces should not be shared with any other application (I say 'should' because they can, but it's a bad idea to do so). Another is dynamic inclusion with static awareness: the application will always be traceable, but will refuse to run if does not find the tracepoint provider library (typically provided by LD_PRELOAD). The tracepoint events can be shared with other applications. The third is dynamic inclusion without static awareness: this operates as the previous, except that when the app does not find the tracepoint provider it runs normally but is not traceable. Turning off traceability in this way does give you a very small gain in performance. The last is fully dynamic inclusion: the app is responsible for its own traceability because it loads and unloads its tracepoint provider itself (using dlopen and dlclose). This is more intrusive as the app's code needs to include this aspect, possibly reflected in its user interface (by a menu item, for instance). On the good side it does mean you get the slight performance gain on demand. If the very slight loss of performance due to tracing doesn't bother you, your best bet is probably dynamic inclusion without static awareness (third option). LTTng can then be configured to capture your app's traces using an on-disc circular buffer (see the tracefile-size and tracefile-count options of the enable-channel command). When your app misbehaves, you suspend it, suspend tracing (lttng stop), and copy the trace to a working directory. You can then babeltrace it or use the Eclipse LTTng views to analyse the trace. This works even better if your app is run multiple times, because then LTTng will capture each running separately (see the buffers-pid and buffers-uid options of the enable-channel command). You only need to remember to flush the older traces once you've decided you don't need them anymore. Daniel U. Thibault Protection des systèmes et contremesures (PSC) | Systems Protection & Countermeasures (SPC) Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber Security (MCCS) R & D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence R&D Canada - Valcartier (DRDC Valcartier) 2459 route de la Bravoure Québec QC G3J 1X5 CANADA Vox : (418) 844-4000 x4245 Fax : (418) 844-4538 NAC : 918V QSDJ<http://www.travelgis.com/map.asp?addr=918V%20QSDJ> <http://www.travelgis.com/map.asp?addr=918V%20QSDJ> Gouvernement du Canada | Government of Canada <http://www.valcartier.drdc-rddc.gc.ca/>
_______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
