The client's system tracing cannot start without a tracefs (or debugfs)
mount - the tracepoint ids live under it - so starting anyway would
capture no samples.
IsSystemTracingFailed reports a SysTraceStart that the preflight could
not predict (the target exiting between the checks, the kernel rejecting
the event setup); starting anyway would capture no samples.
Polling IsDataPortListening is the only reliable check: probing the port
itself cannot distinguish the client's listener from another process
holding it.
When TRACY_PORT is not pinned the client probes 8086..8105 at startup.
Reserve the first free port up front and hand the already-bound socket
to the client via SetReservedListenSocket, so the reservation is atomic
and the reported port matches what the client listens on. A pinned
TRACY_PORT is validated like --port, since the client pins to any
nonzero value with no fallback.
The name is matched against /proc/<pid>/comm, which the kernel truncates
to 15 characters. Several matches are listed so the user can pick one
with -p; a match is only accepted if /proc/<pid>/exe is readable, which
excludes zombies (they keep a comm but have no executable to map) and
inaccessible processes.
The old preflight opened one generic event, which said little about
whether the client's actual setup would work. PreflightSamplingEvent now
opens the client's exact external event shape (the per-CPU pid-filtered
CPU_CLOCK callstack event of SysTraceStart), verifies the ring mmap
works, and probes the hardware PMU counters informationally. On
EACCES/EPERM retry user-space only - both event and callchain, since the
callchain part still requires perf_allow_kernel - and report kernel
frames as unavailable; any other error is fatal, as the client's
identical shape would fail the same way.
kill(pid, 0) succeeds for zombies, so a SIGKILLed attach target whose
parent had not reaped it yet kept the monitor polling indefinitely - in
attach mode the monitor cannot reap it. Liveness now also reads the
/proc state and treats Z as dead.
A thread exiting between fopen and read leaves the comm and status
buffers under-filled or uninitialized: zero-initialize them, treat a
short or empty read as unknown, and never scan the status when the read
returned nothing.
A task directory yielding no numeric entries (the target exiting
mid-enumeration) returned 0 with the freshly allocated array still
handed back through *out, and the caller's failure path returned without
freeing it.
SysTraceStart only failed when no event of any kind opened, but in
external mode the global sched/vsync tracepoints (pid -1) succeed
independently of the target: a target exiting after thread enumeration
left every per-target open failing while the startup still reported
success. s_ctxBufferIdx is the per-target ring count right after the
per-target setup, so in external mode require it to be non-zero as well.
The previous external shape - one per-task (cpu = -1) inherit event per
existing thread - cannot be mmap'd at all: perf_mmap() in
kernel/events/core.c refuses inherited per-task counters (-EINVAL, all
children would write the same ring), so no sample ring was ever created.
A per-CPU event filtered on the target's tgid (the self-profiling shape)
only covers the group leader; the kernel does not retro-inherit onto
pre-existing sibling threads.
Open one CPU-gated event per ring instead - perf_event_open(attr, pid,
cpu), one open per CPU and per target thread, the same shape as perf's
open loop (tools/perf/util/evsel.c:3031). The thread enumeration picks
the fan-out: at launch, per-CPU events on the target pid, inherited by
every later-spawned thread; on attach, per-thread per-CPU events for
every existing tid. Failing opens degrade gracefully: the affected
thread is simply not sampled.
Add PERF_SAMPLE_IP to the callstack sample: for code compiled without
frame pointers the kernel delivers no user stack, and such samples were
dropped entirely. When the callchain count is zero, synthesize a
one-frame trace holding just the leaf IP.
The seven sampling event setups repeated the same open/mmap/retry
sequence. On a refused open the retry now stays user-space only
(exclude_kernel and exclude_callchain_kernel both still require
perf_allow_kernel), and a failed open no longer breaks out of the whole
event loop.
The worker must key source and symbol transfers on the target's
executable, not the monitor's own binary; the exe mtime was read
straight from /proc/<pid>/exe by InitExternalTarget (the readlink'd path
is namespace-dependent and carries a " (deleted)" suffix). For an
external target the time may be unavailable, so drop the assert on a
nonzero exectime.
For an external target the symbol code query addresses are VMAs in the
target's address space, not pointers in the monitor's, so read them out
with ReadExternalTargetMemory. Kernel code (the top bit marks it) is
shared by the monitor and its target alike, so the kernel path applies
in both modes.
ReadExternalTargetMemory reads bytes out of the target's address space:
process_vm_readv for live bytes (gated like ptrace access), falling back
to the target's on-disk image located by scanning /proc/<pid>/maps
directly - the caller runs while the symbol thread may be rebuilding the
shared image cache on refresh.
The resolver previously captured only the first pcinfo result, so inline
frames were lost, and reported ELF virtual addresses the server could
never re-map to the target. Mirror the in-process pcinfo+syminfo flow,
and report symAddr as the target VMA (loadBias + ELF vaddr) so the
server's re-queries can resolve it.
backtrace_create_state_for_file opens the file lazily on first use and,
on a failed open, silently falls back to /proc/self/exe - so a state
created from a path the monitor cannot open would symbolize the target's
addresses against the monitor's own binary. Probe the target's root path
(and, for unlinked images, the mapping's map_files entry), and only
create a state for a path that actually opens.
The list only ever added entries, so a mapping the target re-mapped or
unloaded stayed in the list and could shadow the new mapping or keep
serving an already-unloaded library. Rebuild it from the target's
current maps on each refresh, carrying over the cached backtrace state
for unchanged mappings and dropping entries the current maps no longer
confirm. The dropped entries' paths are abandoned rather than freed:
queued callstack items still carry the path pointer, which the worker
thread reads at its own pace. Strip the kernel's " (deleted)" suffix so
unlinked images converge to their canonical path.
The minVaddr heuristic assumes the mapping's file offset is measured
against the lowest PT_LOAD vaddr of the image. The kernel maps each
PT_LOAD independently, at load_bias + ELF_PAGESTART(p_vaddr) from
p_offset - ELF_PAGEOFFSET(p_vaddr) (fs/binfmt_elf.c, elf_map), so the
assumption only holds for the segment carrying the minimum vaddr. Match
the mapping to its PT_LOAD through the exact offset relation the kernel
used, and take the base from that segment's own vaddr; the minVaddr
heuristic remains as the fallback. The header must be ELF64
(e_ident[4]): the fixed-size elf_ehdr/elf_phdr structs misparse other
classes, and a false segment match on misparsed headers would return a
silently wrong base.
The image paths from /proc/<pid>/maps are only valid in the target's
mount namespace, so resolve them through /proc/<pid>/root (proc(5)). For
unlinked images the kernel keeps the bytes alive in the mapping's
map_files entry, which is opened directly instead.
The state opens the file lazily on first use (fileline_initialize), so
it must own the filename: the caller's buffer may be freed as soon as
this returns. Pass a copy into backtrace_create_state.
`pip install mcp` now installs 2.x by default (v1 is
maintenance-only going forward), and nothing in this repo pinned a
version, so a fresh install already broke: v2 removed
mcp.server.fastmcp entirely, no compat shim.
- Import/class: mcp.server.fastmcp.FastMCP ->
mcp.server.mcpserver.MCPServer.
- Transport options (host, port, sse_path, streamable_http_path)
moved off the constructor and the settings object onto run();
mutating mcp_server.settings.port now raises ValueError.
- _http_ping and the startup message read _SSE_PATH/
_STREAMABLE_HTTP_PATH constants instead of settings.sse_path/
settings.streamable_http_path -- v2 no longer exposes them to
read back. Values match the SDK's own defaults in both versions
("/sse", "/mcp"), so served paths are unchanged.
- Adds extra/mcp/requirements.txt (mcp>=2.0.0,<3) -- there was no
dependency manifest at all before this.
Decorator API is unchanged; every tool/resource here was already
async def, so the "sync handlers now run on worker threads" change
doesn't apply.
Verified in an isolated venv (mcp 2.0.0): module imports cleanly
with all 10 tools and 2 resources registered, the server starts
and serves streamable-http on the expected path, and _http_ping
correctly reports a running instance as alive.
