strace无法追踪malloc等内存分配函数调用，因其仅监控系统调用，而malloc在用户态通过ptmalloc缓存管理；应使用ld_preload、valgrind、asan或perf uprobes进行真实分配行为分析。
Strace 本身不支持直接追踪内存分配函数（如 malloc、calloc、realloc、free）的调用，因为它只跟踪系统调用（system calls），而这些内存函数是 C 标准库（glibc）提供的用户态封装，底层可能调用 brk 或 mmap 等系统调用，但绝大多数分配行为并不直接对应一次系统调用。
为什么 strace -e trace=brk,mmap,munmap 只能看底层映射，不是“内存分配调用”
glibc 的 malloc 实现（ptmalloc）会预先向内核申请大块内存（通过 mmap 或扩展 brk），再在用户态维护空闲链表，后续 malloc 调用大多从这块缓存中切分，不触发新系统调用。因此：
-
strace -e trace=brk,mmap,munmap只能看到进程向内核申请/释放虚拟内存区域的动作，无法反映应用层实际调用了多少次malloc - 它不能显示分配大小、调用栈、分配位置（源码行号）、是否泄漏等关键信息
- 对调试“为什么某处分配了大量内存”或“哪个函数反复 malloc”基本无效
真正分析内存分配调用的正确方法
要捕获所有 malloc/free 等调用，需使用运行时插桩或动态链接劫持技术：
-
LD_PRELOAD + 自定义 malloc wrapper：编译一个共享库，重定义
malloc、free等符号，加入日志或堆栈打印，再用LD_PRELOAD=./libtrace_malloc.so ./your_program运行 -
Valgrind + memcheck：运行
valgrind --tool=memcheck --track-origins=yes ./your_program，可精确记录每次分配/释放的位置、大小、调用栈，并检测越界、泄漏 -
AddressSanitizer (ASan)：编译时加
-fsanitize=address -g，运行时报错时自动打印完整调用栈，对检测非法内存操作和定位分配点极有效 -
perf + uprobes（高级）：Linux 4.17+ 支持对用户态函数打 uprobe，例如
perf probe -x /lib/x86_64-linux-gnu/libc.so.6 malloc，再用perf record -e probe_libc:malloc抓取调用事件（需 debuginfo 包）
快速上手示例：用 LD_PRELOAD 打印 malloc 调用
新建 trace_malloc.c：
#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>
#include <execinfo.h><p>static void<em> (</em>real_malloc)(size_t) = NULL;</p>
<p>void<em> malloc(size_t size) {
if (!real_malloc) real_malloc = dlsym(RTLD_NEXT, "malloc");
void</em> ptr = real_malloc(size);
if (ptr) {
void* stack[20];
int nptrs = backtrace(stack, 20);
backtrace_symbols_fd(stack, nptrs, STDERR_FILENO);
fprintf(stderr, "malloc(%zu) = %p\n", size, ptr);
}
return ptr;
}</p></execinfo.h></dlfcn.h></stdlib.h></stdio.h>编译并使用：
gcc -shared -fPIC -o libtrace.so trace_malloc.c -ldl LD_PRELOAD=./libtrace.so ./your_program
补充说明：strace 在内存分析中的合理定位
strace 仍有价值，但仅限于特定场景：
- 确认程序是否频繁调用
mmap(MAP_ANONYMOUS)（如某些分配器或大页策略） - 观察
brk增长趋势，粗略判断堆是否持续扩张 - 排查因
mmap失败导致的 OOM（如mmap: Cannot allocate memory） - 结合
/proc/PID/maps分析内存布局变化
