fix futexctn tool for symbol resolution and infinite loop - #5496
fix futexctn tool for symbol resolution and infinite loop#5496dubeyabhishek wants to merge 2 commits into
Conversation
There was a problem hiding this comment.
Pull request overview
This PR aims to fix futexctn issues around user-space stack symbol resolution (especially for short-lived processes) and prevent an infinite loop during histogram map cleanup.
Changes:
- Updated
syms_cache__get_syms()behavior to try to refresh cached symbols on cache hits. - Changed
futexctnhistogram cleanup to snapshot keys before deleting them to avoid looping. - Added a symbol “preload” pass intended to populate the symbol cache ahead of stack printing.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| libbpf-tools/trace_helpers.c | Modifies symbol cache lookup/refresh behavior in syms_cache__get_syms(). |
| libbpf-tools/futexctn.c | Adds symbol-cache preloading and changes map cleanup to delete snapshotted keys. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Preload symbol cache entries in the wait loop of futexctn to handle processes that exit before print_stack is invoked. Previously, syms_cache__get_syms was called lazily at print time. For short-lived processes that exit before Ctrl-C is delivered, /proc/<tgid>/maps no longer exists at print time, causing syms__load_pid to return NULL and stack traces to show "failed to get syms" or "[unknown]" for all frames. Fix this by preloading the symbol cache in wait loop throughout the collection interval. This ensures symbols are loaded while the traced process is still alive, and remain available in the cache for symbol resolution even after the process has exited. Signed-off-by: Abhishek Dubey <adubey@linux.ibm.com>
Snapshot hists map keys before cleanup to bound the number of entries to delete. The cleanup loop iterated the hists map while the BPF program continued inserting new entries in parallel. Passing a deleted key back to bpf_map_get_next_key caused the kernel to return the first available key, which could be a newly inserted entry, making the loop non-terminating. Fix this by snapshotting all existing keys into a heap-allocated array before deletion. The cleanup loop then deletes only the finite set of snapshotted keys, leaving any new entries inserted by BPF during cleanup intact for the next interval. Signed-off-by: Abhishek Dubey <adubey@linux.ibm.com>
|
@ekyooo I have addressed the earlier comments. can we have it merged? |
|
@ekyooo @yonghong-song @chenhengqi Please review the v2 changes. Let me know if anything else needed. |
|
Hi everyone, looking for any feedback on this change. |
| * sym expected to be cached in preload stage | ||
| * too late to cache here for short lived processes | ||
| * proc/pid/maps not available to cache | ||
| */ |
There was a problem hiding this comment.
Could we address this using blazesym's blaze_symbolize_cache_process() instead of changing the existing symbol cache infrastructure?
| lookup_key.pid_tgid = -1; | ||
| while (!bpf_map_get_next_key(fd, &lookup_key, &next_key)) { | ||
| err = bpf_map_delete_elem(fd, &next_key); | ||
| while (!bpf_map_get_next_key(fd, &lookup_key, &next_key) && |
There was a problem hiding this comment.
Could we use dump_hash() with lookup_and_delete = true here? See biotop.c for an example.
Please find detailed description of "stack symbol resolution" and "infinite loop behavior in map cleanup" in corresponding commit message.