Track Events not being enabled from trace config? Arm Linux (Yocto Kirkstone based)

[Andrew Haigh]

Hi,

I am having trouble getting track_event enabled as described in the Tracing SDK docs:

https://perfetto.dev/docs/instrumentation/tracing-sdk#track-events

TLDR: Why is the track_event data source not being parsed/enabled from trace config file?

System:

Arm64 Yocto kirkstone based system (April 2024 era Kernel)

Perfetto binaries: built from main branch, and copied the key binaries to the system:

trace box, traced, traced_probes, perfetto

FTrace support configured in the kernel bps layer (didn't work following the Yocto tools-profile addition recommended :( )

Tracing SDK (perfetto.cc and perfetto.h from branch v50.1 as per the web page)

I followed the example on the webpage with CMake, it compiles and links with the Perfetto SDK.

I can run the example, and capture traces using the mentioned scheduling.cfg. I get a sensible trace with cpu usage, example process is shown running etc.

But I think that I am not getting the track_event data source enabled, it seems not even to be mentioned in the trace box logs, even when it does mention linux.ftrace and linux.process_stats for example.

I am simply adding this to the tests/configs/scheduling.cfg file at the end of the file:

data_sources { config { name: "track_event" track_event_config { enabled_categories: "rendering" disabled_categories: "*" } } }

Is there anything else I need to do to make that work? Does it need some specific events in /sys/kernel/tracing to be present for example, beyond those which already enable me to view e.g. cpu usage and thread state etc? I tried using wildcard '*' enable but made no difference. It seems as though its not recognising that data source when parsing the config file?

I am able to rebuild and modify the Perfetto trace box etc with additional instrumentation/logging etc to investigate it further if you need more information?

Thanks,

Andrew

[Lalit Maganti]

Did you configure your SDK to use the system backend: https://perfetto.dev/docs/instrumentation/tracing-sdk#system-mode

That's important if you're trying to get app + system traces.

--
You received this message because you are subscribed to the Google Groups "Perfetto Development - www.perfetto.dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to perfetto-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/perfetto-dev/d6b45161-0b4b-4ee2-b304-46ed149e33a6n%40googlegroups.com.

[Andrew Haigh]

Hi,

Yes I did include that in the example app

What I really suspect is happening is that the problem lies in the enabling of that category when tracebox reads the config file; I just get the feeling its being skipped/goes wrong because it does not mention that as a data source. I know it's reading the right file because I can see it takes account of e.g. buffer size changes or trace duration. 

That said, on re-reading the docs, I think it may be I have not actually started the traced daemon...or should tracebox have started that automatically? This was all I ran (with the example.cc app run separately at the same time):

out/linux/tracebox -o trace_file.perfetto-trace --txt -c test/configs/scheduling.cfg

(I don't have the system to hand to check right now, but will look later today).

Maybe I should recheck the fine manual...

Thanks,

Andrew

[Lalit Maganti]

If using tracebox, you will need to use --system-sockets option as, by default, it uses a temporary socket path which is not accessible for the SDK to connect to

Alternatively, you could run `tracebox traced`, `tracebox traced_probes` and `tracebox perfetto -o trace_file.perfetto-trace --txt -c test/configs/scheduling.cfg` separately: this is generally the most solid way to get system + app tracing working.

To view this discussion visit https://groups.google.com/d/msgid/perfetto-dev/b403ca41-2489-4da8-96e4-0775cc345572n%40googlegroups.com.

[Andrew Haigh]

Hi,

Thanks for the suggestion, I will give that a try tomorrow and see what results.

I appreciate the support.

Thanks,

Andrew Haigh