Uh oh!
There was an error while loading. Please reload this page.
gh-138122: Add blocking mode for accurate stack traces in Tachyon - #142998
Conversation
bb510c0 to
8c21dc9Comparepablogsal
commented
Dec 20, 2025
@ivonastojanovic can you take a look? |
de4448b to
c270764CompareNon-blocking sampling reads process memory while the target continues running, which can produce torn stacks when generators or coroutines rapidly switch between yield points. Blocking mode uses atomic process suspension (task_suspend on macOS, NtSuspendProcess on Windows, PTRACE_SEIZE on Linux) to stop the target during each sample, ensuring consistent snapshots. Use blocking mode with longer intervals (1ms+) to avoid impacting the target too much. The default non-blocking mode remains best for most cases since it has zero overhead. Also fix a frame cache bug: the cache was including the last_profiled_frame itself when extending with cached data, but this frame was executing in the previous sample and its line number may have changed. For example, if function A was sampled at line 6, then execution continued to line 10 and called B→C, the next sample would incorrectly report A at line 6 (from cache) instead of line 10. The fix uses start_idx + 1 to only trust frames ABOVE last_profiled_frame — these caller frames are frozen at their call sites and cannot change until their callees return. Signed-off-by: Pablo Galindo <pablogsal@gmail.com>
| // Extend frame_info with frames from start_idx onwards | ||
| PyObject *slice = PyList_GetSlice(entry->frame_list, start_idx, num_frames); | ||
| // Extend frame_info with frames ABOVE start_idx (not including it). |
There was a problem hiding this comment.
This fixes a frame cache bug: the cache was including the last_profiled_frame
itself when extending with cached data, but this frame was executing in
the previous sample and its line number may have changed. For example,
if function A was sampled at line 6, then execution continued to line 10
and called B→C, the next sample would incorrectly report A at line 6
(from cache) instead of line 10. The fix uses start_idx + 1 to only trust
frames ABOVE last_profiled_frame: these caller frames are frozen at their
call sites and cannot change until their callees return.
ivonastojanovic
left a comment
There was a problem hiding this comment.
LGTM! Just a couple of nits
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Co-authored-by: ivonastojanovic <80911834+ivonastojanovic@users.noreply.github.com>
bedevere-bot
commented
Dec 23, 2025
🤖 New build scheduled with the buildbot fleet by @pablogsal for commit 5438b66 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F142998%2Fmerge If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again. |
Uh oh!
There was an error while loading. Please reload this page.
KowalskiThomas
commented
Jun 1, 2026
👋 Hello! Seems like Is that something you're aware of / looking into already? |
Non-blocking sampling reads process memory while the target continues
running, which can produce torn stacks when generators or coroutines
rapidly switch between yield points. Blocking mode uses atomic process
suspension (task_suspend on macOS, NtSuspendProcess on Windows,
PTRACE_SEIZE on Linux) to stop the target during each sample, ensuring
consistent snapshots.
Use blocking mode with longer intervals (1ms+) to avoid impacting the
target too much. The default non-blocking mode remains best for most
cases since it has zero overhead.
📚 Documentation preview 📚: https://cpython-previews--142998.org.readthedocs.build/