从自身内部访问进程的堆元数据

Question

虽然我可以编写合理的 C 代码，但我的专长主要是 Java，所以如果这个问题没有意义，我深表歉意。

我正在编写一些代码来帮助我进行堆分析。我通过使用 LLVM 进行检测来做到这一点。我正在寻找的是一种从自身内部访问进程的堆元数据的方法。这样的事情可能吗？我知道有关堆的信息存储在许多malloc_state 结构中（例如main_arena）。如果我可以访问main_arena，我可以开始枚举不同的竞技场、堆、垃圾箱等。据我了解，这些变量都是静态定义的，因此无法访问。

但是有什么方法可以获取这些信息吗？例如，我可以使用/proc/$pid/mem 以某种方式泄露信息吗？

一旦我有了这些信息，我想基本上得到关于所有不同空闲列表的信息。因此，对于每种 bin 类型中的每个 bin，我想要 bin 中的块数及其大小。对于快速、小型和 tcache 箱，我知道我只需要索引来确定大小。我已经研究了这些结构是如何实现的以及如何遍历它们。所以我所需要的就是访问这些内部结构。

我查看了malloc_info，这是我的后备方案，但我也想获得有关tcache 的信息，我认为malloc_info 中不包含这些信息。

我考虑过的一个选项是构建一个自定义版本的 glibc，以非静态方式声明 malloc_struct 变量。但据我所知，构建自己的自定义 glibc 并不是很简单，因为您必须构建整个工具链。我正在使用clang，所以我必须根据我的自定义glibc从源代码构建LLVM（至少这是我通过研究这种方法所理解的）。

Answer 1

我最近有一个类似的要求，所以我确实认为能够为给定进程访问main_arena 确实有其价值，例如事后内存使用分析。

使用dl_iterate_phdr和elf.h，根据本地符号解析main_arena相对简单：

#define _GNU_SOURCE
#include <fcntl.h>
#include <link.h>
#include <signal.h>
#include <stdio.h>
#include <string.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <sys/types.h>

// Ignored:
// - Non-x86_64 architectures
// - Resource and error handling
// - Style
static int cb(struct dl_phdr_info *info, size_t size, void *data)
{
  if (strcmp(info->dlpi_name, "/lib64/libc.so.6") == 0) {
    int fd = open(info->dlpi_name, O_RDONLY);
    struct stat stat;
    fstat(fd, &stat);
    char *base = mmap(NULL, stat.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
    Elf64_Ehdr *header = (Elf64_Ehdr *)base;
    Elf64_Shdr *secs = (Elf64_Shdr*)(base+header->e_shoff);
    for (unsigned secinx = 0; secinx < header->e_shnum; secinx++) {
      if (secs[secinx].sh_type == SHT_SYMTAB) {
        Elf64_Sym *symtab = (Elf64_Sym *)(base+secs[secinx].sh_offset);
        char *symnames = (char *)(base + secs[secs[secinx].sh_link].sh_offset);
        unsigned symcount = secs[secinx].sh_size/secs[secinx].sh_entsize;
        for (unsigned syminx = 0; syminx < symcount; syminx++) {
          if (strcmp(symnames+symtab[syminx].st_name, "main_arena") == 0) {
            void *mainarena = ((char *)info->dlpi_addr)+symtab[syminx].st_value;
            printf("main_arena found: %p\n", mainarena);
            raise(SIGTRAP);
            return 0;
          }
        }
      }
    }
  }
  return 0;
}

int main()
{
  dl_iterate_phdr(cb, NULL);
  return 0;
}

dl_iterate_phdr 用于获取映射的 glibc 的基地址。该映射不包含所需的符号表 (.symtab)，因此必须再次映射该库。最终地址由基地址加符号值决定。

(gdb) run
Starting program: a.out 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff77f0700 (LWP 24834)]
main_arena found: 0x7ffff7baec60

Thread 1 "a.out" received signal SIGTRAP, Trace/breakpoint trap.
raise (sig=5) at ../sysdeps/unix/sysv/linux/raise.c:50
50    return ret;
(gdb) select 1
(gdb) print mainarena
$1 = (void *) 0x7ffff7baec60 <main_arena>
(gdb) print &main_arena
$3 = (struct malloc_state *) 0x7ffff7baec60 <main_arena>

该值与main_arena的值匹配，因此找到了正确的地址。

还有其他ways 可以在不依赖库本身的情况下访问main_arena。例如，遍历现有堆允许发现 main_arena，但该策略远不那么简单。

当然，一旦您拥有main_arena，您需要所有内部类型定义才能检查数据。

Answer 2

我正在编写一些代码来帮助我进行堆分析。

什么样的堆分析？

我想基本上获得有关所有不同空闲列表的信息。因此，对于每种 bin 类型中的每个 bin，我想要 bin 中的块数及其大小。对于 fast、small 和 tcache bin，我知道我只需要索引来确定大小。

此信息仅在您计划更改malloc 实现时才有意义。如果您的目标是分析或改善 应用程序 的堆使用情况，尝试收集它确实不有意义，所以听起来你有一个XY problem。

此外，bin 和 tcache 之类的内容仅在特定 malloc 实现的上下文中才有意义（TCMalloc 和 jemalloc 没有任何 bin）。

为了分析应用程序堆的使用情况，您可能希望使用 TCmalloc，因为它为heap profiling 和自省提供了很多工具。