@@ -153,6 +153,10 @@ Attach to a running process by PID::
153153
154154 python -m profiling.sampling attach 12345
155155
156+ Print a single snapshot of a running process's stack::
157+
158+ python -m profiling.sampling dump 12345
159+
156160Use live mode for real-time monitoring (press ``q `` to quit)::
157161
158162 python -m profiling.sampling run --live script.py
@@ -173,8 +177,9 @@ Enable opcode-level profiling to see which bytecode instructions are executing::
173177Commands
174178========
175179
176- Tachyon operates through two subcommands that determine how to obtain the
177- target process.
180+ Tachyon operates through several subcommands. ``run `` and ``attach `` collect
181+ samples over time; ``dump `` captures a single snapshot; ``replay `` converts
182+ binary profiles to other formats.
178183
179184
180185The ``run `` command
@@ -217,6 +222,78 @@ On most systems, attaching to another process requires appropriate permissions.
217222See :ref: `profiling-permissions ` for platform-specific requirements.
218223
219224
225+ .. _dump-command :
226+
227+ The ``dump `` command
228+ --------------------
229+
230+ The ``dump `` command prints a single snapshot of a running process's Python
231+ stack and exits, similar to a traceback::
232+
233+ python -m profiling.sampling dump 12345
234+
235+ Unlike ``attach ``, ``dump `` does not run a sampling loop: it reads the
236+ stack once. This is useful for investigating hung or unresponsive
237+ processes, or for answering "what is this process doing right now?".
238+
239+ The output mirrors a traceback (most recent call last) and annotates each
240+ thread with its current state (main thread, has GIL, on CPU, waiting for
241+ GIL, has exception, or idle):
242+
243+ .. code-block :: text
244+
245+ Stack dump for PID 12345, thread 140735 (main thread, has GIL, on CPU; most recent call last):
246+ File "server.py", line 28, in serve
247+ await handle_request(req)
248+ File "handler.py", line 91, in handle_request
249+ result = expensive_call(req)
250+
251+ When the target's source files are readable, ``dump `` prints the source
252+ line for each frame and highlights the executing expression.
253+
254+ Like ``attach ``, ``dump `` requires permission to read the target process's
255+ memory. See :ref: `profiling-permissions `.
256+
257+ The ``dump `` command supports the following options:
258+
259+ ``-a ``, ``--all-threads ``
260+ Dump every thread in the target process. Without this flag only the main
261+ thread is shown.
262+
263+ ``--native ``
264+ Include synthetic ``<native> `` frames marking transitions into C
265+ extensions or other non-Python code.
266+
267+ ``--no-gc ``
268+ Hide the synthetic ``<GC> `` frames that mark active garbage collection.
269+
270+ ``--opcodes ``
271+ Annotate each frame with the bytecode opcode the thread is currently
272+ executing (for example, ``opcode=CALL_KW ``). Useful for
273+ instruction-level investigation, including identifying specializations
274+ chosen by the adaptive interpreter.
275+
276+ ``--async-aware ``
277+ Reconstruct stacks across ``await `` boundaries. ``dump `` walks the task
278+ graph and emits one section per task, with ``<task> `` markers separating
279+ coroutines awaiting each other.
280+
281+ ``--async-mode {running,all} ``
282+ Controls which tasks are included when ``--async-aware `` is enabled.
283+ ``running `` shows only the task currently executing on each thread;
284+ ``all `` (the default for ``dump ``) also includes tasks suspended on a
285+ wait. ``attach ``'s default for this flag is ``running ``; ``dump ``
286+ defaults to ``all `` because a single snapshot is most useful when it
287+ shows the full task graph.
288+
289+ ``--blocking ``
290+ Pause every thread in the target while reading its stack and resume
291+ them after. Guarantees a fully consistent snapshot at the cost of
292+ briefly stopping the target. Without it, ``dump `` reads memory while
293+ the target keeps running, which is faster but can occasionally produce
294+ a torn stack.
295+
296+
220297.. _replay-command :
221298
222299The ``replay `` command
@@ -1441,11 +1518,52 @@ Global options
14411518
14421519 Attach to and profile a running process by PID.
14431520
1521+ .. option :: dump
1522+
1523+ Print a single one-shot snapshot of a running process's Python stack.
1524+
14441525.. option :: replay
14451526
14461527 Convert a binary profile file to another output format.
14471528
14481529
1530+ Dump options
1531+ ------------
1532+
1533+ The following options apply to the ``dump `` subcommand:
1534+
1535+ .. option :: -a , --all-threads
1536+
1537+ Dump all threads in the target process instead of just the main thread.
1538+
1539+ .. option :: --native
1540+
1541+ Include ``<native> `` frames for non-Python code.
1542+
1543+ .. option :: --no-gc
1544+
1545+ Exclude ``<GC> `` frames for active garbage collection.
1546+
1547+ .. option :: --opcodes
1548+
1549+ Show bytecode opcode names when available.
1550+
1551+ .. option :: --async-aware
1552+
1553+ Reconstruct the stack across ``await `` boundaries for asyncio
1554+ applications.
1555+
1556+ .. option :: --async-mode <mode >
1557+
1558+ Async stack mode: ``running `` (only the running task) or ``all ``
1559+ (all tasks including waiting). Defaults to ``all `` for ``dump ``.
1560+ Requires :option: `--async-aware `.
1561+
1562+ .. option :: --blocking
1563+
1564+ Pause all threads in the target process while reading the stack.
1565+
1566+
14491567Sampling options
14501568----------------
14511569
0 commit comments