Describe the bug

If async-profiler detects a dlopen call, it will patch the opened library to hook certain method calls such as malloc & nested dlopen calls

The problem happens if a lib has the sequence of dlopen -> dlclose -> dlopen operations done one it,
Due to how the linker & memory allocation is handled it is possible that the second dlopen will return the library allocated to the same address as the original dlopen, this means that even though the lib was unloaded & reloaded (Shared objects were deleted & recreated) it will appear identical to the original opened library.

This will cause the async-profiler to incorrectly mark this new library as already patched and skip it causing the async-profiler to not correctly monitor certain calls made inside this library such as nested dlopen (Propagation of issue) & memory allocations (possible hidden memory leaks)

Expected vs. actual behavior

async-profiler shouldn't skip a previously patched library if the shared objects were recreated (unloaded & loaded back again)

Reproduction Steps

For simplicity I would recommend using the new test found here #1243

replace the if (!dlopenFirst) body to look like the following

lib = dlopen("libcallsmalloc.so", RTLD_NOW);
dlclose(lib);
lib = dlopen("libcallsmalloc.so", RTLD_NOW);
...

Additional Information/Context

No response

Async-profiler version

latest

Environment details

No response