Problems with arrays of floats (lttng 2.13)

Problems with arrays of floats (lttng 2.13)

[Herman Bruyninckx via lttng-dev]

Dear all,

I want to trace an array of floats, but I always get bogus output at the
(Python) Babeltrace2 site...
I have no problems with arrays of integers, though.

Is the float array feature not yet implemented in lttng 2.13?
Will it be in 2.14? (Also the "BLOB" feature is useful for me.)

Thanks for your help.

Herman

Re: Problems with arrays of floats (lttng 2.13)

[Kienan Stewart via lttng-dev]

Hi Herman,

On 5/9/25 6:03 AM, Herman Bruyninckx via lttng-dev wrote:
> Dear all,
> 
> I want to trace an array of floats, but I always get bogus output at the
> (Python) Babeltrace2 site...

could you give an example of the tracepoint you have setup in your code 
that doesn't work, with the corresponding output?

Could you explain what you mean by (Python) babeltrace2 site?

Are you instrumenting python code, or are you instrumenting a C/C++ 
application with lttng-ust?

> I have no problems with arrays of integers, though.
> 
> Is the float array feature not yet implemented in lttng 2.13?
> Will it be in 2.14? (Also the "BLOB" feature is useful for me.)
> 

I don't see any changes in lttng-ust for 2.14 that allow for tracepoints 
that have float arrays or blobs. lttng-modules 2.14 does add support for 
CTF 2. The support for CTF 2 in lttng-tools 2.14 will remain at an 
experimental level.

 From the release notes:

       CTF 2 output isn't enabled by default and is intended solely for
       preview and feedback purposes: having an experimental support will
       allow users to test and evaluate CTF 2 until we make it the
       default output format.


> Thanks for your help.
> 
> Herman

thanks,
kienan

[1]: 
https://git.lttng.org/?p=lttng-tools.git;a=blob_plain;f=ChangeLog;hb=11f963148df9597de6d891d96d748bae5ced7149

Re: Problems with arrays of floats (lttng 2.13)

[Herman Bruyninckx via lttng-dev]

[-- Attachment #1: Type: text/plain, Size: 4140 bytes --]

On Fri, 9 May 2025, Kienan Stewart wrote:

> Hi Herman,
>
> On 5/9/25 6:03 AM, Herman Bruyninckx via lttng-dev wrote:
>> Dear all,
>> 
>> I want to trace an array of floats, but I always get bogus output at the
>> (Python) Babeltrace2 site...
>
> could you give an example of the tracepoint you have setup in your code that 
> doesn't work, with the corresponding output?

Thank you for your swift reaction. Much appreaciated.

First of all, my apologies: I should have provided the required information the first time around already.

---
This is the information about the installed versions of the relevant software:

$ uname -a
Linux SET-L-ME-P22061 6.11.0-24-generic #24-Ubuntu SMP PREEMPT_DYNAMIC Fri Mar 14 18:13:56 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

$ lttng -V
lttng (LTTng Trace Control) 2.13.13 - Nordicité

$ babeltrace2 -V
Babeltrace 2.0.6 "Amqui"
---


---
My application code generates a trace as follows:

Tracepoint "-tp.h":
LTTNG_UST_TRACEPOINT_EVENT(
     comm_activity,
     range_scan,

     /* Input arguments */
     LTTNG_UST_TP_ARGS(
         int *, distances,
     ),

     /* Output event fields */
     LTTNG_UST_TP_FIELDS(
         lttng_ust_field_array(int, distances,distances,5)
)


int testmeas[5] = {1, 2, 3, 4, 5};
// double testmeas[5] = {1., 2., 3., 4., 5.};
// (one array for test with integers, one with doubles):

lttng_ust_tracepoint(comm_activity,range_scan,5,testmeas, "range_scan");

---

> Could you explain what you mean by (Python) babeltrace2 site?
This is the Python code I use to display the trace generated above:
(inspired by <https://babeltrace.org/docs/v2.0/python/bt2/examples.html>)

---
file tt.py:

import bt2
import sys

# Get the trace path from the first command-line argument.
path = sys.argv[1]

# Create a trace collection message iterator with this path.
msg_it = bt2.TraceCollectionMessageIterator(path)

# Iterate the trace messages.
for msg in msg_it:
     # `bt2._EventMessageConst` is the Python type of an event message.
     if type(msg) is bt2._EventMessageConst:
         # An event message holds a trace event.
         event = msg.event
         # Only check `range_scan` events.
         if event.name != 'comm_activity:range_scan':
             continue
         print(event.payload_field)
---

and these are the resulting traces (for int and double, respectively, and with the C and Python versions of Babeltrace):

$ babeltrace2  ~/git-repositories/communication_5c/build/test_session/
[12:19:11.381152129] (+?.?????????) SET-L-ME-P22061 comm_activity:range_scan: { cpu_id = 6 }, { distances = [ [0] = 1, [1] = 2, [2] = 3, [3] = 4, [4] = 5 ] }

$ python3 tt.py  ~/git-repositories/communication_5c/build/test_session/
{'distances': [1, 2, 3, 4, 5]}

----

bt2$ babeltrace2  ~/git-repositories/communication_5c/build/test_session/
[10:04:51.068836215] (+?.?????????) SET-L-ME-P22061 comm_activity:range_scan: { cpu_id = 6 }, { distances = [ [0] = 0, [1] = 1072693248, [2] = 0, [3] = 1073741824, [4] = 0 ] }

$ python3 tt.py  ~/git-repositories/communication_5c/build/test_session/
{'distances': [0, 1072693248, 0, 1073741824, 0]}

> Are you instrumenting python code, or are you instrumenting a C/C++ 
> application with lttng-ust?

The latter.

>> I have no problems with arrays of integers, though.
>> 
>> Is the float array feature not yet implemented in lttng 2.13?
>> Will it be in 2.14? (Also the "BLOB" feature is useful for me.)
>> 
>
> I don't see any changes in lttng-ust for 2.14 that allow for tracepoints that 
> have float arrays or blobs. lttng-modules 2.14 does add support for CTF 2. 
> The support for CTF 2 in lttng-tools 2.14 will remain at an experimental 
> level.
>
> From the release notes:
>
>      CTF 2 output isn't enabled by default and is intended solely for
>      preview and feedback purposes: having an experimental support will
>      allow users to test and evaluate CTF 2 until we make it the
>      default output format.
>
>
>> Thanks for your help.
>> 
>> Herman
>
> thanks,
> kienan

Herman

> [1]: 
> https://git.lttng.org/?p=lttng-tools.git;a=blob_plain;f=ChangeLog;hb=11f963148df9597de6d891d96d748bae5ced7149
>
>

Re: Problems with arrays of floats (lttng 2.13)

[Kienan Stewart via lttng-dev]

Hi Herman,

On 5/10/25 4:14 AM, Herman Bruyninckx wrote:
> On Fri, 9 May 2025, Kienan Stewart wrote:
> 
>> Hi Herman,
>>
>> On 5/9/25 6:03 AM, Herman Bruyninckx via lttng-dev wrote:
>>> Dear all,
>>>
>>> I want to trace an array of floats, but I always get bogus output at the
>>> (Python) Babeltrace2 site...
>>
>> could you give an example of the tracepoint you have setup in your 
>> code that doesn't work, with the corresponding output?
> 
> Thank you for your swift reaction. Much appreaciated.
> 
> First of all, my apologies: I should have provided the required 
> information the first time around already.
> 
> ---
> This is the information about the installed versions of the relevant 
> software:
> 
> $ uname -a
> Linux SET-L-ME-P22061 6.11.0-24-generic #24-Ubuntu SMP PREEMPT_DYNAMIC 
> Fri Mar 14 18:13:56 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
> 
> $ lttng -V
> lttng (LTTng Trace Control) 2.13.13 - Nordicité
> 
> $ babeltrace2 -V
> Babeltrace 2.0.6 "Amqui"
> ---
> 
> 
> ---
> My application code generates a trace as follows:
> 
> Tracepoint "-tp.h":
> LTTNG_UST_TRACEPOINT_EVENT(
>      comm_activity,
>      range_scan,
> 
>      /* Input arguments */
>      LTTNG_UST_TP_ARGS(
>          int *, distances,
>      ),
> 
>      /* Output event fields */
>      LTTNG_UST_TP_FIELDS(
>          lttng_ust_field_array(int, distances,distances,5)
> )
> 
> 
> int testmeas[5] = {1, 2, 3, 4, 5};
> // double testmeas[5] = {1., 2., 3., 4., 5.};
> // (one array for test with integers, one with doubles):
> 
> lttng_ust_tracepoint(comm_activity,range_scan,5,testmeas, "range_scan");
> 
> ---
> 
>> Could you explain what you mean by (Python) babeltrace2 site?
> This is the Python code I use to display the trace generated above:
> (inspired by <https://babeltrace.org/docs/v2.0/python/bt2/examples.html>)
> 
> ---
> file tt.py:
> 
> import bt2
> import sys
> 
> # Get the trace path from the first command-line argument.
> path = sys.argv[1]
> 
> # Create a trace collection message iterator with this path.
> msg_it = bt2.TraceCollectionMessageIterator(path)
> 
> # Iterate the trace messages.
> for msg in msg_it:
>      # `bt2._EventMessageConst` is the Python type of an event message.
>      if type(msg) is bt2._EventMessageConst:
>          # An event message holds a trace event.
>          event = msg.event
>          # Only check `range_scan` events.
>          if event.name != 'comm_activity:range_scan':
>              continue
>          print(event.payload_field)
> ---
> 
> and these are the resulting traces (for int and double, respectively, 
> and with the C and Python versions of Babeltrace):
> 
> $ babeltrace2  ~/git-repositories/communication_5c/build/test_session/
> [12:19:11.381152129] (+?.?????????) SET-L-ME-P22061 
> comm_activity:range_scan: { cpu_id = 6 }, { distances = [ [0] = 1, [1] = 
> 2, [2] = 3, [3] = 4, [4] = 5 ] }
> 
> $ python3 tt.py  ~/git-repositories/communication_5c/build/test_session/
> {'distances': [1, 2, 3, 4, 5]}
> 
> ----
> 
> bt2$ babeltrace2  ~/git-repositories/communication_5c/build/test_session/
> [10:04:51.068836215] (+?.?????????) SET-L-ME-P22061 
> comm_activity:range_scan: { cpu_id = 6 }, { distances = [ [0] = 0, [1] = 
> 1072693248, [2] = 0, [3] = 1073741824, [4] = 0 ] }
> 
> $ python3 tt.py  ~/git-repositories/communication_5c/build/test_session/
> {'distances': [0, 1072693248, 0, 1073741824, 0]}
> 
>> Are you instrumenting python code, or are you instrumenting a C/C++ 
>> application with lttng-ust?
> 
> The latter.

thanks for the extra info, it's much clearer to me now!

When you're passing the pointer to the array of floats, you get the 
weird values because there's not an explicit type conversion so the raw 
data of the floats is being interpreted as integer values.

As there is no lttng-ust function to handle an array of floats at this 
point there's a few other options you could try.

In your example you're using a fixed length array, so it's possible to 
define a tracepoint with 5 floats like this

```
/* note, this version isn't doing any bounds checking */
LTTNG_UST_TRACEPOINT_EVENT(
   my_provider
   my_tracepoint
   LTTNG_UST_TP_ARGS(
     float*, my_float_array_ptr
   )
   LTTNG_UST_TP_FIELDS(
     lttng_ust_field_float(float, float0, my_float_array_ptr[0])
     lttng_ust_field_float(float, float1, my_float_array_ptr[1])
     ...
     lttng_ust_field_float(float, float4, my_float_array_ptr[4])
   )
)
```

Here's a couple of ideas for a more general approach

1. Define a tracepoint with an integer length, maybe the base pointer 
identifier (for correlation) and the offset. You'd have to have a 
smaller helper that calls the tracepoint one or more times depending on 
the length of your array.

Something a bit like the following. Note that I didn't do a full test.

```
LTTNG_UST_TRACEPOINT_EVENT(
   my_provider,
   my_tracepoint,
   LTTNG_UST_TP_ARGS(
     float*, my_float_array_ptr,
     size_t, my_float_array_len,
     size_t, my_float_array_offset,
   )
   LTTNG_UST_TP_FIELDS(
    lttng_ust_field_integer_hex(void*, array_ptr, my_float_array_ptr)
    lttng_ust_field_integer(size_t, array_len, my_float_array_len,
    lttng_ust_field_integer(size_t, array_offset, my_float_array_offset),
    lttng_ust_field_float(float, float1, (my_float_array_offset + 0 >= 
my_float_array_len) ? 0.0 : my_float_array_ptr[my_float_array_offset + 0])
    lttng_ust_field_float(float, float1, (my_float_array_offset + 1 >= 
my_float_array_len) ? 0.0 : my_float_array_ptr[my_float_array_offset + 1])
    ...
    lttng_ust_field_float(float, float1, (my_float_array_offset + n >= 
my_float_array_len) ? 0.0 : my_float_array_ptr[my_float_array_offset + n])
   )
)
```

2. or, use a structure with N floats and a process similar to the above.

It's a bit inelegant until there is support for array of floats in 
lttng-ust.

3. Use the int or char array and rebuild the float values in post



Hope this gives you an option to work with for the moment.

thanks,
kienan

>>> I have no problems with arrays of integers, though.
>>>
>>> Is the float array feature not yet implemented in lttng 2.13?
>>> Will it be in 2.14? (Also the "BLOB" feature is useful for me.)
>>>
>>
>> I don't see any changes in lttng-ust for 2.14 that allow for 
>> tracepoints that have float arrays or blobs. lttng-modules 2.14 does 
>> add support for CTF 2. The support for CTF 2 in lttng-tools 2.14 will 
>> remain at an experimental level.
>>
>> From the release notes:
>>
>>      CTF 2 output isn't enabled by default and is intended solely for
>>      preview and feedback purposes: having an experimental support will
>>      allow users to test and evaluate CTF 2 until we make it the
>>      default output format.
>>
>>
>>> Thanks for your help.
>>>
>>> Herman
>>
>> thanks,
>> kienan
> 
> Herman
> 
>> [1]: https://git.lttng.org/?p=lttng- 
>> tools.git;a=blob_plain;f=ChangeLog;hb=11f963148df9597de6d891d96d748bae5ced7149
>>
>>

Re: Problems with arrays of floats (lttng 2.13)

[Herman Bruyninckx via lttng-dev]

[-- Attachment #1: Type: text/plain, Size: 7362 bytes --]

On Tue, 13 May 2025, Kienan Stewart wrote:

> Hi Herman,
>
> On 5/10/25 4:14 AM, Herman Bruyninckx wrote:
>> On Fri, 9 May 2025, Kienan Stewart wrote:
>> 
>>> Hi Herman,
>>> 
>>> On 5/9/25 6:03 AM, Herman Bruyninckx via lttng-dev wrote:
>>>> Dear all,
>>>> 
>>>> I want to trace an array of floats, but I always get bogus output at the
>>>> (Python) Babeltrace2 site...
>>> 
>>> could you give an example of the tracepoint you have setup in your code 
>>> that doesn't work, with the corresponding output?
>> 
>> Thank you for your swift reaction. Much appreaciated.
>> 
>> First of all, my apologies: I should have provided the required information 
>> the first time around already.
>> 
>> ---
>> This is the information about the installed versions of the relevant 
>> software:
>> 
>> $ uname -a
>> Linux SET-L-ME-P22061 6.11.0-24-generic #24-Ubuntu SMP PREEMPT_DYNAMIC Fri 
>> Mar 14 18:13:56 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
>> 
>> $ lttng -V
>> lttng (LTTng Trace Control) 2.13.13 - Nordicité
>> 
>> $ babeltrace2 -V
>> Babeltrace 2.0.6 "Amqui"
>> ---
>> 
>> 
>> ---
>> My application code generates a trace as follows:
>> 
>> Tracepoint "-tp.h":
>> LTTNG_UST_TRACEPOINT_EVENT(
>>      comm_activity,
>>      range_scan,
>>
>>      /* Input arguments */
>>      LTTNG_UST_TP_ARGS(
>>          int *, distances,
>>      ),
>>
>>      /* Output event fields */
>>      LTTNG_UST_TP_FIELDS(
>>          lttng_ust_field_array(int, distances,distances,5)
>> )
>> 
>> 
>> int testmeas[5] = {1, 2, 3, 4, 5};
>> // double testmeas[5] = {1., 2., 3., 4., 5.};
>> // (one array for test with integers, one with doubles):
>> 
>> lttng_ust_tracepoint(comm_activity,range_scan,5,testmeas, "range_scan");
>> 
>> ---
>> 
>>> Could you explain what you mean by (Python) babeltrace2 site?
>> This is the Python code I use to display the trace generated above:
>> (inspired by <https://babeltrace.org/docs/v2.0/python/bt2/examples.html>)
>> 
>> ---
>> file tt.py:
>> 
>> import bt2
>> import sys
>> 
>> # Get the trace path from the first command-line argument.
>> path = sys.argv[1]
>> 
>> # Create a trace collection message iterator with this path.
>> msg_it = bt2.TraceCollectionMessageIterator(path)
>> 
>> # Iterate the trace messages.
>> for msg in msg_it:
>>      # `bt2._EventMessageConst` is the Python type of an event message.
>>      if type(msg) is bt2._EventMessageConst:
>>          # An event message holds a trace event.
>>          event = msg.event
>>          # Only check `range_scan` events.
>>          if event.name != 'comm_activity:range_scan':
>>              continue
>>          print(event.payload_field)
>> ---
>> 
>> and these are the resulting traces (for int and double, respectively, and 
>> with the C and Python versions of Babeltrace):
>> 
>> $ babeltrace2  ~/git-repositories/communication_5c/build/test_session/
>> [12:19:11.381152129] (+?.?????????) SET-L-ME-P22061 
>> comm_activity:range_scan: { cpu_id = 6 }, { distances = [ [0] = 1, [1] = 2, 
>> [2] = 3, [3] = 4, [4] = 5 ] }
>> 
>> $ python3 tt.py  ~/git-repositories/communication_5c/build/test_session/
>> {'distances': [1, 2, 3, 4, 5]}
>> 
>> ----
>> 
>> bt2$ babeltrace2  ~/git-repositories/communication_5c/build/test_session/
>> [10:04:51.068836215] (+?.?????????) SET-L-ME-P22061 
>> comm_activity:range_scan: { cpu_id = 6 }, { distances = [ [0] = 0, [1] = 
>> 1072693248, [2] = 0, [3] = 1073741824, [4] = 0 ] }
>> 
>> $ python3 tt.py  ~/git-repositories/communication_5c/build/test_session/
>> {'distances': [0, 1072693248, 0, 1073741824, 0]}
>> 
>>> Are you instrumenting python code, or are you instrumenting a C/C++ 
>>> application with lttng-ust?
>> 
>> The latter.
>
> thanks for the extra info, it's much clearer to me now!
>
> When you're passing the pointer to the array of floats, you get the weird 
> values because there's not an explicit type conversion so the raw data of the 
> floats is being interpreted as integer values.
>
> As there is no lttng-ust function to handle an array of floats at this point 
> there's a few other options you could try.
>
> In your example you're using a fixed length array, so it's possible to define 
> a tracepoint with 5 floats like this
>
> ```
> /* note, this version isn't doing any bounds checking */
> LTTNG_UST_TRACEPOINT_EVENT(
>  my_provider
>  my_tracepoint
>  LTTNG_UST_TP_ARGS(
>    float*, my_float_array_ptr
>  )
>  LTTNG_UST_TP_FIELDS(
>    lttng_ust_field_float(float, float0, my_float_array_ptr[0])
>    lttng_ust_field_float(float, float1, my_float_array_ptr[1])
>    ...
>    lttng_ust_field_float(float, float4, my_float_array_ptr[4])
>  )
> )
> ```
>
> Here's a couple of ideas for a more general approach
>
> 1. Define a tracepoint with an integer length, maybe the base pointer 
> identifier (for correlation) and the offset. You'd have to have a smaller 
> helper that calls the tracepoint one or more times depending on the length of 
> your array.
>
> Something a bit like the following. Note that I didn't do a full test.
>
> ```
> LTTNG_UST_TRACEPOINT_EVENT(
>  my_provider,
>  my_tracepoint,
>  LTTNG_UST_TP_ARGS(
>    float*, my_float_array_ptr,
>    size_t, my_float_array_len,
>    size_t, my_float_array_offset,
>  )
>  LTTNG_UST_TP_FIELDS(
>   lttng_ust_field_integer_hex(void*, array_ptr, my_float_array_ptr)
>   lttng_ust_field_integer(size_t, array_len, my_float_array_len,
>   lttng_ust_field_integer(size_t, array_offset, my_float_array_offset),
>   lttng_ust_field_float(float, float1, (my_float_array_offset + 0 >= 
> my_float_array_len) ? 0.0 : my_float_array_ptr[my_float_array_offset + 0])
>   lttng_ust_field_float(float, float1, (my_float_array_offset + 1 >= 
> my_float_array_len) ? 0.0 : my_float_array_ptr[my_float_array_offset + 1])
>   ...
>   lttng_ust_field_float(float, float1, (my_float_array_offset + n >= 
> my_float_array_len) ? 0.0 : my_float_array_ptr[my_float_array_offset + n])
>  )
> )
> ```
>
> 2. or, use a structure with N floats and a process similar to the above.
>
> It's a bit inelegant until there is support for array of floats in lttng-ust.
>
> 3. Use the int or char array and rebuild the float values in post
>
>
>
> Hope this gives you an option to work with for the moment.

Definitely! Much appreciated :-)

> thanks,
> kienan

Herman

>>>> I have no problems with arrays of integers, though.
>>>> 
>>>> Is the float array feature not yet implemented in lttng 2.13?
>>>> Will it be in 2.14? (Also the "BLOB" feature is useful for me.)
>>>> 
>>> 
>>> I don't see any changes in lttng-ust for 2.14 that allow for tracepoints 
>>> that have float arrays or blobs. lttng-modules 2.14 does add support for 
>>> CTF 2. The support for CTF 2 in lttng-tools 2.14 will remain at an 
>>> experimental level.
>>> 
>>> From the release notes:
>>> 
>>>      CTF 2 output isn't enabled by default and is intended solely for
>>>      preview and feedback purposes: having an experimental support will
>>>      allow users to test and evaluate CTF 2 until we make it the
>>>      default output format.
>>> 
>>> 
>>>> Thanks for your help.
>>>> 
>>>> Herman
>>> 
>>> thanks,
>>> kienan
>> 
>> Herman
>> 
>>> [1]: https://git.lttng.org/?p=lttng- 
>>> tools.git;a=blob_plain;f=ChangeLog;hb=11f963148df9597de6d891d96d748bae5ced7149
>>> 
>>> 
>
>