KOOM V1.0.5 fork dump方案解析

之前研究KOOM的时候，fork dump方案没有详细研究，最近得空，简单来解析下吧。

内存监控APM都会有个环节：通过Debug.dumpHprofData() dump当前内存镜像hprof文件。

LeakCanaray、Matrix、Probe采用的方案：
直接执行Debug.dumpHprofData()，它执行过程会先挂起当前进程的所有线程，然后执行dump操作，生成完成hprof文件之后再唤醒所有线程。整个过程非常耗时，会带来比较明显的卡顿，因此这个痛点严重影响该功能带到线上环境。

常规dump

KOOM采用的方案:
主进程fork子进程来处理hprof dump操作，主进程本身只有在fork 子进程过程会短暂的suspend VM, 之后耗时阻塞均发生在子进程内，对主进程完全不产生影响。

fork dump

而suspend VM过程时间非常短，从测试结果来看完全可以忽略不计：

快手官方实验数据对比

接下来详细分析下fork dump方案的实现：

forkDump核心业务逻辑如下

java层：

private static void forkDump(String path) throws IOException {
    System.loadLibrary("heap_dump”);//加载so
   
   initVmEnv();//初始化虚拟机环境
   suspendVM();//挂起父进程虚拟机，供fork子进程。

   int pid = fork();//fork 子进程

   if (pid == 0) {
        PerfLog.e("In child process. pid:" + pid);
       Debug.dumpHprofData(path); //dump hprof
       exitProcess();//结束子进程
   } else if (pid > 0) {
        PerfLog.e("In parent process, pid:" + pid);
       resumeVM();//唤醒父进程虚拟机
       waitPid(pid);//接收子进程结束信号，清理僵尸进程
   }
}

private native static boolean initVmEnv();
private native static int fork();
private native static void suspendVM();
private native static void resumeVM();
private native static void waitPid(int pid);
private native static void exitProcess();

为什么需要先suspendVM然后再fork?
起初我理解主要是让fork前后的内存镜像保存一致性，但是对于内存泄漏来说这个造成的影响并不大，demo直接fork好像也没有什么问题，何况这块做了大量工作绕过Android N的限制去suspendVM肯定是有其必要性的。
最终才发现，单线程是没问题的，因为线程已经停了，demo加多线程dump会卡在suspendVM。因此需要先suspendVM，再fork，最后resumeVM。

好，确认工作流之后，来尝试实现：

native层：

这里fork、waitPid 、exitProcess都比较简单，直接忽略，重点看vm相关操作：

正常操作就应该是：

void *libHandle = dlopen("libart.so", RTLD_NOW);//打开libart.so, 拿到文件操作句柄
void *suspendVM = dlsym(libHandle, LIBART_DBG_SUSPEND);//获取suspendVM方法引用
void *resumeVM = dlsym(libHandle, LIBART_DBG_RESUME);//获取resumeVM方法引用
dlclose(libHandle);//关闭libart.so文件操作句柄

这在Android N以下的版本这么操作是OK了，但是对于Android N及其以上版本：对调用系统库做了限制，也就是说不能直接dlopen libart.so了。需要另辟蹊径绕过这个限制，这里先分析下相关的系统源码：
源码参考：Android 9.0

/bionic/libdl/libdl.cpp
02__attribute__((__weak__))
103void* dlopen(const char* filename, int flag) {
104  const void* caller_addr = __builtin_return_address(0);//得到当前函数返回地址
105  return __loader_dlopen(filename, flag, caller_addr);
106}

/bionic/linker/dlfcn.cpp
152void* __loader_dlopen(const char* filename, int flags, const void* caller_addr) {
153  return dlopen_ext(filename, flags, nullptr, caller_addr);
154}

131static void* dlopen_ext(const char* filename,
132                        int flags,
133                        const android_dlextinfo* extinfo,
134                        const void* caller_addr) {
135  ScopedPthreadMutexLocker locker(&g_dl_mutex);
136  g_linker_logger.ResetState();
137  void* result = do_dlopen(filename, flags, extinfo, caller_addr);//执行do_dlopen
138  if (result == nullptr) {
139    __bionic_format_dlerror("dlopen failed", linker_get_error_buffer());
140    return nullptr;
141  }
142  return result;
143}

/bionic/linker/linker.cpp
2049void* do_dlopen(const char* name, int flags,
2050                const android_dlextinfo* extinfo,
2051                const void* caller_addr) {
2052  std::string trace_prefix = std::string("dlopen: ") + (name == nullptr ? "(nullptr)" : name);
2053  ScopedTrace trace(trace_prefix.c_str());
2054  ScopedTrace loading_trace((trace_prefix + " - loading and linking").c_str());
2055  soinfo* const caller = find_containing_library(caller_addr);
2056  android_namespace_t* ns = get_caller_namespace(caller);
...
2141  return nullptr;
2142}

这里dlopen最终执行是通过__loader_dlopen，只不过默认会传入当前函数地址，这个地址其实就是做了caller address校验，如果检测出是三方地址则校验不通过，这里传入系统函数地址则能通过校验，例如dlerror。

那么KOOM的做法是：

> Android N的版本

using __loader_dlopen_fn = void *(*)(const char *filename, int flag, void *address);
void *handle = ::dlopen("libdl.so", RTLD_NOW);//打开libel.so
//这里直接调用其__loader_dlopen方法，它与dlopen区别是可以传入caller address
auto __loader_dlopen = reinterpret_cast<__loader_dlopen_fn>(::dlsym(handle,"__loader_dlopen"));
__loader_dlopen(lib_name, flags, (void *) dlerror);//传入dlerror系统函数地址，保证caller address校验通过，绕过Android N限制。

>=Android Q的版本

因为Q引入了runtime namespace，因此__loader_dlopen返回的handle为nullptr

这里通过dl_iterate_phdr在当前进程中查询已加载的符合条件的动态库基对象地址。

int DlFcn::dl_iterate_callback(dl_phdr_info *info, size_t size, void *data) {
    auto target = reinterpret_cast(data);
   if (info->dlpi_addr != 0 && strstr(info->dlpi_name, target->info_.dlpi_name)) {
        target->info_.dlpi_addr = info->dlpi_addr;
       target->info_.dlpi_phdr = info->dlpi_phdr;
       target->info_.dlpi_phnum = info->dlpi_phnum;
       // break iterate
       return 1;
   }

    // continue iterate
   return 0;
}

dl_iterate_data data{};
data.info_.dlpi_name = "libart.so";
dl_iterate_phdr(dl_iterate_callback, &data);
CHECKP(data.info_.dlpi_addr > 0)
handle = __loader_dlopen(lib_name, flags, (void *) data.info_.dlpi_addr);

这里dl_iterate_callback会回调当前进程所装载的每一个动态库，这里过滤出libart.so对应的地址：data.info_.dlpi_addr，再通过__loader_dlopen尝试打开libart.so。

附：

struct dl_phdr_info {
  ElfW(Addr) dlpi_addr;//基对象地址
  const ElfW(Phdr)* dlpi_phdr;//指针数组
  ElfW(Half) dlpi_phnum;//
...
};

这便是快手自研的kwai-linker组件通过caller address替换和dl_iterate_phdr解析绕过Android 7.0对调用系统库做的限制的具体实现。也是fork dump方案的核心技术点。

参考：
https://bbs.pediy.com/thread-257022.htm
https://blog.csdn.net/linuxheik/article/details/17502433