Bug #612
closedDuplicate events for tracepoints emitted from dlopened shared objects
0%
Description
Since LTTng 2.2 the behavior for lttng enable-event/enable-channel changed in a subtle but annoying way for tracepoints emitted from dlopened shared objects.
The attached sample executable caused exactly one event to get recorded up until LTTng-2.1 when the following lttng command sequence is used:
lttng create
lttng enable-channel ch1 -u
lttng enable-event 'my_events:*' -u -c ch1
lttng enable-channel ch2 -u
lttng enable-event -u -a -c ch2
lttng start
./bin/tpproxytest
lttng stop
lttng destroy
for LTTng <=2.1 babeltrace give us just one event (which is what users would expect):
[17:01:20.816055508] (+?.?????????) atv-pwoegere-l3.atv.mentorg.com:tpproxytest:23702 my_events:event1: { cpu_id = 6 }, { }
for LTTng >=2.2 babeltrace shows that the event got recoded twice (once in ch1 and once again in ch2 ?):
[16:57:08.342747191] (+?.???????) atv-pwoegere-l3.atv.mentorg.com:tpproxytest:5458 my_events:event1: { cpu_id = 5 }, { }
[16:57:08.342753041] (+0.000005850) atv-pwoegere-l3.atv.mentorg.com:tpproxytest:5458 my_events:event1: { cpu_id = 5 }, { }
As already stated, this effect only occurs when the tracepoint gets emitted from a dlopened shared lib. For all other emitted tracepoints the behavior is as it was until LTTng 2.1.
Not sure what could have caused this strange regression but the following commits might have to do with it:
99234da69ab197050d3d28ea428c54e08539667c Fix: tracepoint.h incorrect assumption about constructor order
46c881a7d6839761e3371a93ba29e7a0202bcd03 Fix: tracepoint instrumentation constructor order issue
558b9d86247004f8e9bbaf8c982f3b2b182093d1 Fix: ensure all probe providers have their symbols
Files