Avoid patching symbols in the extension module

The fact that patching ourselves had not raised problems so far its
really an outstanding fact in this universe. Unfortunately seems that
with the latest toolchain + GCC there is something that causes memray to
point the d_original entry of the hooks pointing to itself, which should
never happen.

To fix this resiliently, avoid patching ourselves by getting our own
name in the extension module and then avoiding that shared object.

Author: pablogsal

src/memray/_memray/elf_shenanigans.cpp

@@ -1,4 +1,5 @@
 #include <cstring>
+#include <mutex>
 #include <set>
 #include <string>
 #include <sys/mman.h>
@@ -171,11 +172,23 @@ phdrs_callback(dl_phdr_info* info, [[maybe_unused]] size_t size, void* data) noe
         patched.insert(info->dlpi_name);
     }
 
+    // Get this so name once
+    std::once_flag flag;
+    static std::string self_so_name;
+    std::call_once(flag, [&]() {
+        Dl_info info;
+        if (dladdr((void*)&phdrs_callback, &info)) {
+            self_so_name = info.dli_fname;
+        } else {
+            self_so_name = "_memray.cpython-";
+        }
+        printf("self_so_name: %s\n", self_so_name.c_str());
+    });
+
     if (strstr(info->dlpi_name, "/ld-linux") || strstr(info->dlpi_name, "/ld-musl")
-        || strstr(info->dlpi_name, "linux-vdso.so.1"))
+        || strstr(info->dlpi_name, "linux-vdso.so.1") || strstr(info->dlpi_name, self_so_name.c_str()))
     {
         // Avoid chaos by not overwriting the symbols in the linker.
-        // TODO: Don't override the symbols in our shared library!
         return 0;
     }