Use targeted process to resolve library names

[pchaigno]

This pull request implements the first strategy discussed at #853 to improve the selection of libraries for attach_uprobe.

To resolve library names, bcc_procutils_which_so now leverages mapped libraries of the targeted process, if a PID is given. It uses the kernel's /proc/$pid/maps to extract mapped libraries.

Any other tests I should add?

/cc @vmg @goldshtn

[goldshtn]

Thanks, this looks good (haven't tested yet). Perhaps it would be good to add a test that actually verifies we're picking the right library if there are multiple options?

[pchaigno]

Perhaps it would be good to add a test that actually verifies we're picking the right library if there are multiple options?

I'd like that too. Unless there's already a library (libc?) with multiple versions on all test environments, we'd need to change the environments' setup before.

[pchaigno]

I just updated the pull request to fix an error.

load_mappings loads the mapped libraries of a given process in memory. When bcc_procutils_which_so is called a second time, it reads the mapped libraries directly from memory. I hadn't considered that the given PID can change, in which case we should reload mapped libraries in memory.

[goldshtn]

Not only can the given pid change, but even the same pid can be recycled for another process. I don't know if we want to cache the results at all, and if we do it would have to be careful caching that takes at least the process cmdline into account to try and avoid most recycling cases.

What do others think? @4ast @drzaeus77 @brendangregg @vmg

[4ast]

My understanding is bcc_procutils_which_so() will be called roughly once per script, so caching /proc/pid/maps doesn't help much and makes it error prone for cases when pid is recycled and libbcc is used in long running services. So I like the idea of reading /proc/pid/maps to discover specific .so of given pid, but caching is unnecessary.

[vmg]

I agree. We already have some quirky workarounds in the library to spot and prevent bugs related PID reuse (which is a real issue in busy production systems), so naively caching the output of maps based on PID sounds like a recipe for disaster. This is not performance critical code, so it should be perfectly fine to read maps on each call and skip the caching altogether.

[pchaigno]

I updated the branch to remove the cached libraries 😇

[4ast]

lgtm
cc @goldshtn @vmg