gh-138122: Add blocking mode for accurate stack traces in Tachyon - #142998
gh-138122: Add blocking mode for accurate stack traces in Tachyon#142998pablogsal merged 6 commits into
Conversation
Sorry, something went wrong.
|
@ivonastojanovic can you take a look? |
Sorry, something went wrong.
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. 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.
Sorry, something went wrong.
ivonastojanovic
left a comment
There was a problem hiding this comment.
LGTM! Just a couple of nits
Sorry, something went wrong.
Co-authored-by: ivonastojanovic <80911834+ivonastojanovic@users.noreply.github.com>
|
🤖 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. |
Sorry, something went wrong.
|
👋 Hello! Seems like test_profiling which was added as part of this PR has been failing quite a lot / quite often on Windows on main and feature branches on top of from main lately (one example from a branch of mine, but on main here, here, here and here from recent executions). Is that something you're aware of / looking into already? |
Sorry, something went wrong.
Sorry, something went wrong.
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/