mzhan017的博客

摘要：文章讨论了因未彻底替换malloc相关函数导致的coredump问题。根据GNU说明，必须完整替换所有内存分配函数，否则可能导致静态链接失败或运行时堆损坏。以systemd新版本使用malloc_usable_size为例，若上层应用未同步更新替换该函数，就会引发问题。文中展示了相关代码片段，强调必须关注底层库的内存管理函数变更，确保完整替换整套内存分配函数以避免兼容性问题。

提到了使用masif来分析问题。发现使用这个工具可以查看heap的使用详情，这个是非常有用。有时候使用valgrind的memcheck工具，检查不到问题，因为这个内存一直到程序退出的时候才会释放。工作中肯定会有此类问题。所以这个工具还是相当有用的。

那为什么内存错乱呢？因为这个程序是多线程，主线程已经进入到了exit过程，而上面那个对象所引用的是一个全局对象，所以内存已经被释放，这样已经进入到了未定义行为状态。出现coredump也不为过。发现这里的vtable的指针指向的完全不算SocketStream 类的虚函数表，而是INetSocket类的，所以说是内存完全就错乱了。dump这个虚函数表内容。这样算下来，call的地址就是0了，所有就出现了问号的显示。反汇编frame-1，dump寄存器。通过p命令查看stream对象。

这里的0x9c83c是一个字节数，不用再乘4. 641084+260729*4 = 1684000，这个可以计算ok没问题。最后发现，是传递进来的源内存地址空间，在copy的时候超出了时间new出来的内存空间。也就是第三个参数的值传递进来的错误了。根据esi/edi的值和传递进来的参数对比，差值是0x9c83c，说明已经copy了这么多的数据。在实际的内存分配是：638976，和641084差不多，所以可能还是内存分配的问题。memcpy传递进来的参数值。还是在说是内存访问错误。

这里是iMessages向量的第i个元素，然后调用所存类的成员函数：IncomingMessage。提示：You can’t do that without a process to debug.如果有一个vector的变量，在程序里可能使用所以来使用比如。怎么看这个vector里的内容呢？

在glibc的sysdeps/i386/i686/memcpy.S文件理，memcpy函数，在代码段理会向栈push一个eax，然后在调用movsl的时候出现coredump，这个时候，push eax这个操作会导致栈上的内容不全，从而导致gdb推理出现混乱。其实要根据gdb function backtrace的实现来说，它就是依据当时的esp/ebp寄存器的值，来往前推理整个函数调用栈。function backtrace如下，而且frame-1显示是一个无效的代码地址，然后显示了问号。

这个方法的副作用是，会将所有的错误都输出到/dev/null，万一是其他命令执行错误，需要查看错误信息的时候，就不好办了，比如，如果一个数据类型的大小超过了max-value-size的大小，会有一个错误的提示，这个时候就看不到了，需要注意。如果编译gdb，不带python的支持，运行的时候会有下面这个提示，调试的时候，每一步都可能打出来这个警告，非常不友好，其实打一次就够了。所以可以考虑，将这个错误导向一个不用的临时文件？怎么抑制这个警告不停的打印呢？这个方法，会遇到问题。

这个错误是什么意思，如果在这里可以打印出来说，/s不是合法的反汇编指令的修饰器，可能更容易理解。但是这个也是没有跑了，就是 /s 用错误了。之前有影响说这个 /s 就是查看源代码行号的一个选项，在这里为什么不能用了呢？有可能记忆出现偏差。info line linespec，来获取行号。应该使用 /m选项来查看源代码行号。

如果一个程序设置了 RLIMIT_FSIZE 为 40M，那么该程序启动的子进程（例如 gzip）的 RLIMIT_FSIZE 也会是 40M。资源限制是从父进程继承到子进程的，因此子进程会继承父进程的 RLIMIT_FSIZE 设置。具体来说，当父进程启动子进程时，子进程会继承父进程的所有资源限制，包括文件大小限制。这意味着，如果父进程将 RLIMIT_FSIZE 设置为 40M，那么子进程（如 gzip）也会受到相同的 40M 文件大小限制。

原因是gcc做了优化，使用到了浮点类型的指令，这个指令要求是存储地址是16字节对齐，如果不对齐，就会coredump。产生coredump的地址是栈上的一个地址，之前一直没有想明白为什么没有对齐，按照理论是gcc来做对齐，然后gcc做优化使用浮点指令。所以一切都在gcc的操控范围之内，怎么产生不一致的可能？昨天凌晨想通了这个问题，是因为工程里有几个文件是直接使用汇编写的，所以对于栈空间汇编代码自己来做的空间分配。所以下一步方向就是看这一部分汇编代码，看看有没有地方产生不对齐的可能。

看着是说错误的unit_type,应该是 1，2，而不应该是4。原因应该是binary是clang编译的，没有带-ggdb选项。最近使用gdb，解析一个同事给的二进制文件，遇到下面的错误。

数据类型不匹配： abc 是一个 unsigned long 类型，而 sprintf 函数的 %u 格式化符用于无符号整数。由于 abc 的值是 0xffffffffffffffff，它超出了 unsigned long 的范围，导致溢出。数组大小不足： link_set_id 数组只有 8 个字节，而 sprintf 函数可能会写入超过 8 个字节的数据，导致缓冲区溢出。即使修改了代码，也需要谨慎处理 unsigned long 类型的值，因为它们可能超出预期范围。这段代码存在潜在问题。

但是带来的后果非常的严重，因为：_leftover_buffer是一个std::string对象，而std::string的data()方法返回的是一个指向内部字符数组的指针，这个数组的大小由字符串的长度决定。memcpy函数会将buffer_len字节的数据从message复制到_leftover_buffer的内部字符数组中，但如果_leftover_buffer的长度小于buffer_len，这将导致未定义行为，因为它会写入超出_leftover_buffer内部数组边界的内存。

最近在调试一个C语言项目时，遇到了一个令人头疼的Coredump问题。经过一番排查，发现问题出在内存管理上。具体来说，是在函数A中设置了一个变量来记录申请内存的个数，但由于后续内存申请失败，导致记录的个数与实际申请成功的内存块数量不一致，最终在释放内存时引发了错误。这个问题看似简单，却暴露了内存管理中一些常见的陷阱。借此机会，我想和大家分享一下我的解决思路，以及如何避免类似问题的发生。内存申请失败是常见的情况，必须进行妥善处理，避免程序出现未定义行为。这可以帮助我们更好地管理内存，避免释放未分配的内存。

【代码】gdb: script: lookup_symbols根据地址dump符号。

这个情况，还是第一次看到，gcc在做优化的时候，对于memset函数，可能使用sse相关的movups/movaps这种指令来提升性能，但是这两个指令的区别是movaps如果碰到非16字节对齐，可能导致coredump。

然后使用rep movsq临时copy到栈内存。然后再使用这个栈的内容。通过查看汇编，这个变量的内容是存放到了一个全局的数据空间。

今天这个问题是说，有一个同事在修改程序做一个POC，修改完成之后tshark抓包发现对方已经给回了heartbeat，但是我端抓的程序日志里没有看到接收到的heartbeat消息。因为修改的代码比较特殊，以为重启就是必然的，所以没有考虑这个重启就是这个heartbeat导致。然后比较晕的是，还在那里想为什么没有在log里打印出来。所以还是不能放过出现问题时，出现的任何奇怪的现象，包括但不限于程序的重启。另外，程序使用了libevent/epoll功能，通过dump，发现就是发生问题时的fd=44。

也许可以使用strace的功能得到一些有用的信息。下面这个例子可以看到向stderr打印的：free(): double free detected in tcache 2。如果这个程序是由其他的程序使用execve的方式带起来，这个程序发生coredump，向stderr的输出可能就没有做处理。维护者可能就看不到这些信息。关键还是需要使用gdb来debug问题。

这个问题的原因是function backtrace里的中间一个函数申请了接近8M的stack，也就是到了临界点。所以出现问题的地方可能是这个函数之后的其他函数调用，这样导致问题分析出现困难。对于stackoverflow的问题，需要关注每个frame的栈的使用情况。这时候就是一个多线程问题，虽然在gdb里这个地址访问没有问题，但是这个地址可能已经是不同thread的内存地址。虽然gdb里能访问，不代表那个出现问题的thread可以访问。出现SEGV是说访问这个地址出现问题。所以这个是什么原因呢？

https://mzhan017.blog.youkuaiyun.com/article/details/144508224，这个链接里提到的第四点，最后忘记NULL的结束标记录入。这次出现的原因是va_list/start/arg使用错误。导致传递到getopt里的argc的数量与实际不符合。需要注意va_list/start/arg的使用事项。

所以这个prctl的调用，应该是在execve之后调用，也就是必须在B的程序里调用。而不是在A进程的fork之后，execve之前。如果是在fork之后，execve之前，更加Linux的execve的系统调用，还是有可能会将mm的flag标记为不可dump。最近和同事一块看为什么没有生成coredump文件，调查发现就是设置PR_SET_DUMPABLE的问题，但是怎么设置都不行。A进程通过fork-execve的方式启动程序B；

从https://lwn.net/Articles/104341/，这个链接里看，如果suid_dumpable设置为2的时候，就是不能被覆盖。但是现在RHEL8，4.18的版本的说明和这个不一样了，还会遵守这个规定吗？

其中比较难的一部分是setuid相关的不匹配问题，因为这里牵扯的新概念非常多，而且和安全/权限相关（也就是说，自己的知识有所欠缺的地方）。如果有需要可以参考。大体上就这么几种情况：信号的特殊处理，coredump相关的配置没有设置正确，文件系统访问权限问题，setuid相关的不匹配问题。最近和同事一块看一个core文件没有产生的问题，总结了一些在优快云的专栏里。分析的过程，参考使用了ftrace的功能，感觉非常实用。

这个错误的引入是在：https://patchwork.ozlabs.org/project/glibc/patch/1510068430-27816-3-git-send-email-pistukem@gmail.com/这个错误“malloc(): mismatching next->prev_size (unsorted)”的原因是什么？heap overflow，写超了。

这个和配置：suid_dumpable相关，但是在什么时候设置上去的呢？是在执行exec的时候，调到commit_creds的时候会用到这个参数。

2022-12-6 遇到一例，释放后继续使用的案例，导致数据错乱，coredump；2024-10-26遇到一例，多线程，一个线程释放之后，另一个线程继续使用出现错误。2022-12-9 Kernel、driver一例；

通过使用ftrace的功能function_graph调试，发现是下面条件没有走进来，为什么没有走进来呢？

默认情况下，kill -11 发送的是 SIGSEGV信号，会导致程序崩溃并生成 core 文件，默认的内核行为。但在某些情况下，SIGSEGV 并不会生成 core 文件。

关于coredump的配置还挺多。原因也说因为安全。有些东西就是需要可以配置的。

今天遇到一个例子，是在进程退出的时候，调用全局对象的析构函数，析构函数里调用了delete操作，但是delete操作，所要释放的指针，虽然不为0，但是之前已经被释放过了，不是合理的malloc内存：corrupted double-linked list。这种大多是多线程导致问题，最好是枷锁保护这个关键指针变量。

这里提到一个问题，就是如果栈被用光了，这个时候SIGSEGV的用户自定义的handler处理可能就没有空间进行处理。这个时候，可以使用sigaltstack函数，将信号处理函数的处理过程在另一个单独的栈里进行。这种情况，一般很少能第一时间想到这个问题。而是出了问题之后，才会找相应的方法，然后找到sigaltstack。算是一步步的涨知识。在上面一篇是关于stack耗尽的一个小程序例子。

但是在安装完glibc-debuginfo之后，做gdb调试的时候，加载glibc的源代码出现这个警告：Source file is more recent than executable。这个的原因是创建的这个学习文件，名称和glibc里的文件名称重名了。把例子文件的名称改一下就好了，可以解决问题。最近做了一件晕事，自己创建了一个syslog.c的文件来学习syslog接口函数。

这个是一个普遍的问题，原因是有时候生产环境中，没有安装gdb所依赖的库软件，导致gdb的安装受阻。这里的第一步就是怎么将依赖库的.a文件都找出来，或者是自己将所有的依赖开源软件都编译出来。最近有朋友问，怎么将所依赖库的.a文件打包到一个文件，然后做变的时候直接依赖这个文件做编译。这一步应该是可以学到东西的最重要的一步。第二步没有必要将所有的.a文件打包到一个文件，只要确保编译/链接的时候能找到相关的文件就可以。第三步，要修改gdb的编译脚本，确保是static编译，确保链接的时候能找到想要的.a文件。

如果xz-devel没有安装，而且自己手动编译安装lzma的路径不是正式的目录（/usr/lib/;/usr/lib64），就需要指定lzma的安装目录，‘–with-lzma-prefix’，这样gdb的configure步骤，才能找到对应的头文件和so文件。这种问题不是lzma独有，其他开源软件的编译安装可能会碰到类似的问题，大多数因为缺少devel包的安装，或者自己手动编译的安装路径设置问题。如果是想编译时带着’–with-lzma’。下面是devel rpm带有的必须的头文件，以及so文件。

最近遇到一个coredump，发生的点是程序试图将动态链接库代码映射的内存置0.所以要确保，结构体发生变更后，所有的目标文件，都需要重新编译。最后发现是数据结构发生改变之后，导致内存访问越界错误。比如，像0xf6d5b000 写入0.

意思是说找不（/usr/lib/debug/usr/lib64/libstdc++.so.6.0.25-8.5.0-20.el8.x86_64.debug需要的）到文件.gnu_debugaltlink。最后的解决方法是安装gcc-debuginfo。因为libstdc+±debuginfo， 依赖这个gcc-debuginfo。还是不能图省事不安装。

最后调查的原因是，是一个静态变量的析构函数已经在进程退出的时候被调用了，但是其他线程的程序还在使用这个静态变量的成员函数，但是这个时候的vtable值已经变了。最近遇到一个coredump，是在进程退出的时候。通过gdb查看core文件，出现的问题是在__cxa_pure_virtual 函数。也就是在对象的构造函数和析构函数里有些纯虚的函数可能被调用，这个函数也是一个错误上报的方式。要避免在进程执行exit的时候，继续线程的运行。这种类型的coredump还真是第一次遇到。gcc里这个函数的定义。

这个时候如果想使用gdb调试程序，gdb的策略是lazy方式加载dwo文件，而且根据indirect（间接）的路径去找dwo文件，如果找不到，就会导致有些变量打印不出来。需要让gdb自己能通过间接路径找到dwo文件。假如使用了gsplit-dwarf选项，而且选择输出dwarf调试信息，这个时候，为了减小可执行文件的大小。链接器会将dwarf的调试信息，单独放到一个新文件里，后缀是dwo。这个时候还不能使用symbol-file/file加载dwo文件。现在还没找到别的好办法。

使用dwp查看clang编译出来的文件，会导致dwp产生coredump。下一步就是要看传递进来的fp为什么是0？