iovisor / iovisor/bcc

Unresolved symbols in profile co-re version

Open
#5,349 11 comments 0 reactions 0 assignees View on GitHub
bug help wanted
Dominant language
C
Stars
22.7k
Forks
4.1k
Avg merge
5d 13h
Merged PRs (30d)
3

Description

Hello,

Why does the profile utility from the libbpf-tool return less detailed stack traces compared to the old version?

- libbpf-tool (10 samples):

```sh
$ /opt/bcc/bin/profile -F49 -d --stack-storage-size=$((1024*1024)) -f -p 1087382 10

Could not open /usr/lib/x86_64-linux-gnu/libc.so.6 (deleted)
Could not open /usr/lib/x86_64-linux-gnu/libpthread.so.0 (deleted)
Could not open /usr/lib/x86_64-linux-gnu/libresolv.so.2 (deleted)
Could not open /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 (deleted)
Sampling at 49 Hertz of PID [1087382] by user + kernel for 10 secs.
[unknown]
[unknown]
[unknown]
[unknown]
[unknown]
[unknown]
- kubelet (1087382)
2

[unknown]
[unknown]
[unknown]
[unknown]
[unknown]
- kubelet (1087382)
...
```

- python (154 samples):

```
$ python3 /opt/bcc/share/bcc/tools/profile -F49 -d --stack-storage-size=$((1024*1024)) -fa -p 1087382 10

Sampling at 49 Hertz of PID [1087382] by user + kernel stack for 10 secs.

__switch_to+0x165 [kernel]
__switch_to+0x165 [kernel]
__schedule+0x2b7 [kernel]
schedule+0x68 [kernel]
futex_wait_queue+0x66 [kernel]
futex_wait+0x151 [kernel]
do_futex+0x178 [kernel]
__x64_sys_futex+0x78 [kernel]
do_syscall_64+0x59 [kernel]
entry_SYSCALL_64_after_hwframe+0x73 [kernel]
--
[unknown] [kubelet]
[unknown] [kubelet]
[unknown] [kubelet]
[unknown] [kubelet]
[unknown] [kubelet]
[unknown] [kubelet]
[unknown] [kubelet]
[unknown] [kubelet]
[unknown] [kubelet]
[unknown] [kubelet]
[unknown] [kubelet]
[unknown] [kubelet]
[unknown] [kubelet]
[unknown] [kubelet]
- kubelet (1087382)
1
...
```

Why so huge difference between python based profile and libbpf based versions?

OS: Ubuntu Jammy 22.04
Linux: 6.2.0

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with the libbpf-tool profile utility and compare its output with the Python profile command shown in the issue on Ubuntu 22.04 and Linux 6.2. Investigate why user and kernel stack symbols become unknown, and consider the issue resolved when the libbpf-based profile provides a comparable, symbolized stack trace or documents the limitation.

Written by the indexing model from the issue text.

Assessment

Tech stack
c, linux
Domain
observability, operating-systems, performance
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.