google/perfetto

Objects with no doc comment get the nearest comment block above the CREATE as their description, even when a blank line separates them. This is usually the license header. For example, _all_counters_per_process in linux/memory/general.sql is described as "Copyright 2024 The Android Open Source Project…", and _graph_scan_df_agg as "sqlformat file off". 17 objects are affected today, all of them internal. Junk descriptions are worse than empty ones. UI autocomplete and agent tooling that read this table present license text as documentation, and these objects no longer look undocumented. Likely cause: LastBlockStart and get_stmt_desc in sql_module_doc_parser.cc take the last block of comments before the statement without checking that it ends directly above the CREATE.

__intrinsic_stdlib_objects reports the wrong argument docs for macros with more than one argument: every argument gets the first argument's comment. For example, graph_table and start_nodes on graph_reachable_bfs in graphs/search.sql both show the graph_table description. This affects roughly 30 of the 78 multi-argument macros. The UI's query editor and DataExplorer take their stdlib docs from this table, so users see wrong docs for public macros like graph_reachable_bfs. Argument docs matter most for macros because the arguments are untyped table and subquery parameters. Likely cause: ExtractMacroArgs in src/trace_processor/util/sql_module_doc_parser.cc uses syntaqlite_node_leading_comments(item_id). PerfettoMacroArg nodes are built inside the left-recursive perfetto_macro_arg_list_ne rule in perfetto.y, and for them this call seems to return the first token of the whole list rather than of each argument. Function and table arguments are unaffected because ExtractArgDefList finds the

Problem If I put TRACE_EVENT or TRACE_EVENT_BEGIN macros inside a lambda, the MSVC compiler runs for infinite time without finish. To reproduce Try to compile this simple code with perfetto v52.0-6942f195e and toolchain: VS 2026 18.10.1, MSVC 14.51.36231, v145, Release x64. I noticed the same problem also with older versions of MSVC. #include <perfetto.h> #include <iostream> PERFETTO_DEFINE_CATEGORIES(perfetto::Category("lambda_test")); PERFETTO_TRACK_EVENT_STATIC_STORAGE(); int main() { perfetto::TracingInitArgs args; args.backends = perfetto::kInProcessBackend; perfetto::Tracing::Initialize(args); perfetto::TrackEvent::Register(); auto traced_lambda = [] { TRACE_EVENT("lambda_test", "LambdaTraceEvent"); std::cout << "Lambda called\n"; }; perfetto::TraceConfig config; config.add_buffers()->set_size_kb(1024); auto session = perfetto::Tracing::NewTrace(); session->Setup(config); session->StartBlocking(); traced_lambda(); perfetto::TrackEvent::Flush(); session->Sto

Following the instructions to download prebuilt trace_processor, it SIGILLs when doing anything as simple as trace_processor --help. This machine is an older Xeon but still x86_64, and it looks like the precompiled binary expects something newer but does not check for it. Following https://perfetto.dev/docs/analysis/trace-processor#shell curl -LO https://get.perfetto.dev/trace_processor chmod +x ./trace_processor gdb --args python ./trace_processor --help run ... Program received signal SIGILL, Illegal instruction. 0x0000555555cea51c in ?? () (gdb) bt #0 0x0000555555cea51c in ?? () #1 0x00005555561b7bd4 in ?? () #2 0x000055555618a7fa in ?? () #3 0x000055555618ea88 in ?? () #4 0x000055555618eca0 in ?? () #5 0x00005555561fbc96 in ?? () #6 0x00007ffff7c27934 in __libc_start_main () from /usr/lib/libc.so.6 #7 0x0000555555aefce5 in ?? () (gdb) x/i $pc => 0x555555cea51c: mulx %rcx,%rcx,%rax /proc/cpuinfo reports E5-2650 and no bmi2 support. I know I can probably build it my

The calltree view is cool but it doesn't do a good job of expanding eagerly in the case where there's only a single possible child. We should eagerly expand on every entry as long as there's only one child.