MattStudiesA tale of @iainireland 's performance win, and the question of: How do you find problems like this in your system if you don't know _what_ you are looking for?
https://www.mgaudet.ca/technical/2025/5/9/a-performance-investigation-challenge
In this vein: Any `bpftrace` wizards out there (please feel free to boost for visibility):
Suppose I have the a trace file like this:
```
uprobe:/home/matthew/unified-git/obj-debug-shell-x86_64-pc-linux-gnu/dist/bin/js:*registerWithRootLists*
{
@call[ustack(perf,3)] = count()
}
uprobe:/home/matthew/unified-git/obj-debug-shell-x86_64-pc-linux-gnu/dist/bin/js:cpp:JS_ShutDown
{
printf("calling exit from ebpf");
exit()
}
```
right now I get unsymbolicated output like this:
```
@call[
55912bd662e0 0x55912bd662e0 ([unknown])
55912bde2918 0x55912bde2918 ([unknown])
55912c053dbd 0x55912c053dbd ([unknown])
]: 1538
```
Which is cool! This is almost certainly the data I'm interested in. But without symbols it's uninterpretable. How on earth can I get this symbolicated?
Zixian Cai@mgaudet I have had this issue before, it’s most likely a timing problem of symbol resolution vs process exit. My workaround is to just put an infinite loop in the VM shutdown routine so bpftrace has a chance to read /proc and resolve symbols. See this issue for more context
@caizixian… hmm. Maybe that’s it. I thought adding the exit probe on shutdown would suffice, but I will try the infinite loop option :)
@caizixian (not today though. Far too late to work today :) )