---
{
    "title": "Minidump",
    "language": "zh-CN"
}
---

<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at

  http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->

# Minidump(removed)

> Minidump 已经被移除，它在实际线上环境中没有用处，反而会引入额外的错误。

Minidump 是微软定义的一种用于程序崩溃后错误上报的文件格式。其中包括了崩溃时的线程信息、寄存器信息、调用栈信息等等，这有助于开发人员快速定位问题。

不同于 [Coredump](https://en.wikipedia.org/wiki/Core_dump)，Minidump 文件体积更小，更易于上报和网络传输。Coredump 文件会包含完整的内存镜像，因此体积可能有几十上百GB。而 Minidump 文件仅包含关键线程的调用栈和寄存器信息，因此体积通常只有 MB 级别。

[Breakpad](https://github.com/google/breakpad) 是一个跨平台的崩溃转储和分析框架和工具集合。用户可以借助 Breakpad 来对 Minidump 文件进行自助分析。也可以收集 Minidump 文件并上报给 Doris 集群运维或开发人员。

## 如何开启 Minidump

Minidump 功能是在 Doris 0.15.0 之后的版本中引入的功能。该功能由 BE 的以下配置文件控制：

* `disable_minidump`

    是否开启 Minidump 功能。默认为 false，即开启。
    
* `minidump_dir`

    Minidump 文件的存储目录。默认为 `${DORIS_HOME}/Minidump/`
    
* `max_minidump_file_size_mb`

    Minidump 文件的大小限制。默认为 200MB。如果大小超过阈值，breakpad 会尝试减少文件中记录的信息，比如线程数量和寄存器数量来介绍 Minidump 的文件大小。但这只是一个期望值，实际文件大小可能比设定的大。
    
* `max_minidump_file_number`

    最多保留多少个 Minidump 文件。默认为 10，既保留最近的 10 个文件。
    
## 如何生成 Minidump

Minidump 的生成有两种方式：

1. 程序崩溃

    当程序遇到问题崩溃后，会自动生成 Minidump 文件。此时会在 be.out 中出现如下信息：
    
    ```
    Minidump created at: /doris/be/Minidump/4f8d4fe5-15f8-40a3-843109b3-d49993f3.dmp
    *** Aborted at 1636970042 (unix time) try "date -d @1636970042" if you are using GNU date ***
    PC: @          0x1b184e4 doris::OlapScanNode::scanner_thread()
    *** SIGSEGV (@0x0) received by PID 71567 (TID 0x7f173a5df700) from PID 0; stack trace: ***
    @          0x220c992 google::(anonymous namespace)::FailureSignalHandler()
    @     0x7f174fb5e1d0 (unknown)
    @          0x1b184e4 doris::OlapScanNode::scanner_thread()
    @          0x15a19af doris::PriorityThreadPool::work_thread()
    @          0x21d9107 thread_proxy
    @     0x7f174fb53f84 start_thread
    @     0x7f174f943ddf __GI___clone
    @                0x0 (unknown)
    ```
    
    其中 `/doris/be/Minidump/4f8d4fe5-15f8-40a3-843109b3-d49993f3.dmp` 为 Minidump 文件。而其后的堆栈是程序崩溃点所在的调用栈信息。
    
2. 手动触发

    用户可以主动地向 BE 进程发送 SIGUSR1 信号来触发 Minidump。如使用以下命令：
    
    ```
    kill -s SIGUSR1 71567
    ```
    
    其中 71567 是 BE 的进程id（pid）。之后，会在 be.out 中出现如下信息：
    
    ```
    Receive signal: SIGUSR1
    Minidump created at: /doris/be/Minidump/1af8fe8f-3d5b-40ea-6b76ad8f-0cf6756f.dmp
    ```

    其中 `Receive signal: SIGUSR1` 表示这是用户触发的 Minidump 操作。后面是 Minidump 文件位置。
    
    用户手动触发的 Minidump 操作不会杀死 BE 进程，并且不会在 be.out 产生错误堆栈。
    
## 如何分析 Minidump

我们可以使用 breakpad 提供的各类工具来分析 Minidump，从而查看错误原因。

### 获取 breakpad 工具

用户可以自行前往 [Breakpad](https://github.com/google/breakpad) 代码库下载并编译 breakpad。编译方式可以参考 Doris 源码库中的 [thirdparty/vars.sh](https://github.com/apache/incubator-doris/blob/master/thirdparty/vars.sh) 中的 `build_breakpad()` 方法。

也可以在 Doris 提供的 Docker 编译镜像 1.4.2 以上版本中，从镜像容器的 `/var/local/thirdparty/installed/bin` 目录下找到 breakpad 编译产出的各类工具。

### 分析 Minidump

我们可以使用以下两种方式来分析 Minidump 文件。

1. 转储成 coredump 文件

    使用 breakpad 提供的 `minidump-2-core` 工具将 Minidump 文件转储成 coredump 文件：
    
    ```
    ./minidump-2-core /doris/be/Minidump/1af8fe8f-3d5b-40ea-6b76ad8f-0cf6756f.dmp > 1.coredump
    ```
    
    之后我们可以使用 gdb 工具来分析这个 coredump 文件了：
    
    ```
    gdb lib/doris_be -c 1.coredump
    ```

2. 生成可读调用栈

    Minidump 文件中只包含调用栈的地址，我们需要把这些地址对应到实际的函数文件位置。因此，我们首先需要通过 `dump_syms ` 生成 BE 二进制文件的符号表 `doris_be.sym`：
    
    ```
    ./dump_syms ./lib/doris_be > doris_be.sym
    ```

    接下来，我们需要符号表第一行的信息，构建一个对应的符号表目录。
    
    ```
    head -n1 doris_be.sym
    ```
    
    以上命令会打印 doris_be.sym 的第一行内容如下：
    
    ```
    MODULE Linux x86_64 137706CC745F5EC3EABBF730D4B229370 doris_be
    ```
    
    之后我们创建一个目录结构：
    
    ```
    mkdir -p ./symbols/doris_be/137706CC745F5EC3EABBF730D4B229370
    ```
    
    目录路径中的 `doris_be` 和 `137706CC745F5EC3EABBF730D4B229370` 需和 doris_be.sym 文件的第一行内容一致。然后我们将 doris_be.sym 文件移动到该目录中：
    
    ```
    cp doris_be.sym ./symbols/doris_be/137706CC745F5EC3EABBF730D4B229370
    ```
    
    最后，我们可以使用 `minidump_stackwalk` 来产出可读的调用栈信息：
    
    ```
    minidump_stackwalk 4f8d4fe5-15f8-40a3-843109b3-d49993f3.dmp ./symbols/ > readable.stack
    ```
    
    其中 `4f8d4fe5-15f8-40a3-843109b3-d49993f3.dmp` 为 minidump 文件。`./symbols/` 为之前创建的包含 doris_be.sym 的目录。`readable.stack` 是将生成的结果重定向到这个文件中。同时，在执行这个命令时，屏幕上也会刷一些程序运行日志，可以不用理会。
    
    至此，我们就获取了一个可读的线程调用栈文件：readable.stack。其中包含了 BE 程序在写 Minidump 文件时的所有线程的调用栈信息，以及对应的寄存器信息。
    
    其中 `Crash reason` 说明了程序崩溃的原因。如果是 `DUMP_REQUESTED`，则表示这是一次用户主动触发的 Minidump。
    
    我们可以通过以下命令过滤掉寄存器信息，从而获取一个比较清晰的调用栈视图：
    
    ```
    grep -v = readable.stack |grep -v "Found by" |vi -
    ```
    
    其结果比较类似于通过 pstack 命令获取到的线程调用栈信息。