async-profiler does not hook indirect dlopens

[yanglong1010]

Hi,

I encountered this problem by chance, not in a real-world scenario.

• JDK opens a native library lib1, it provides JNI implementation to Java code.
• A function of lib1 dlopens another library lib2, and calls a function f_2 in lib2.
• f_2 calls malloc, dlopens lib3, and calls a function named f_3 in lib3.
• f_3 calls may call malloc

The cpu profile produced by perf is like this:

If take cpu profile, all cstack modes fail to walk the methods of lib2 and lib3.
If take native mem profile, all mallocs in lib2 and lib3 are missing.

The probability of this case is very low. I just wonder it is necessary to add this missing piece.
In addition to hook every dlopen, some other details needs to be handled carefully. Such as RPATH, if libA dlopens libB, glibc reads the RAPTH from libA and uses it to search libB. if dlopen is hooked by async-profiler, the caller of dlopen becomes async-profiler rather than libA, async-profiler should walk the RPATH of libA manually to find libB, then invokes dlopen with the absolute path.

[apangin]

You are right: async-profiler does not immediately track shared objects dlopen'ed from libraries other than libjvm.so, unless these objects are loaded automatically via DT_NEEDED. This was a conscious trade-off. Alternatives considered were:

1. Patching dlopen GOT entry in all shared objects - this is somewhat dangerous.
2. Periodic refresh of the loaded library list - this incurs additional overhead and does not solve the problem completely (there is still a time window between a newly loaded library has been loaded and parsed).
3. Relying on perf_events for PERF_RECORD_MMAP2 or tracepoints - does not work in containers.

As you've mentioned, this problem is rare, and it is automatically solved upon starting the next profiling session. So I'm inclined not to fix it unless you know a simple and safe approach to tackle this.