由于在 C 中实现的 erl_interface 库导致内存损坏 [重复]答案

【问题标题】：Memory corruption due to erl_interface libraries that are implemented in C [duplicate]由于在 C 中实现的 erl_interface 库导致内存损坏 [重复]
【发布时间】：2017-09-02 15:43:04
【问题描述】：

在我的应用程序中，我有一个 erlang 节点，它定期与 C-node每1秒收集一次报警、性能等周期性数据。

C节点的实现方式是，它由两个线程组成，main线程接收来自erlang节点的请求并将消息传递给worker线程。 worker 线程为 erlang 节点提供查询和回复。回复 erlang 节点的所有在 cnode 中收集的数据需要转换为 erlang 格式（在我的例子中是一个元组列表）使用函数erl_format。

这里观察到的问题是，在运行大约 45 分钟后，我遇到了 glibc 错误，它抱怨内存损坏。

这可能是什么原因？

我使用的是 3.9 版本的 erl_interface 编译的库带有线程安全选项（例如 _REENTRANT）

请在我得到的日志下面找到 glibc 抱怨可能的内存损坏

当我在地址 0x101bb12c 上执行addr2line 时，它指向 erl_format()

*** glibc detected *** /root/rel-1.0.0/galaxy/lib/galaxy-1.6.0/priv/hyphy_cnode: malloc(): memory corruption (fast): 0x1021fb08 ***
======= Backtrace: =========
/lib/libc.so.6[0xfd84610]
/lib/libc.so.6[0xfd864fc]
/lib/libc.so.6(__libc_malloc+0xb4)[0xfd887b8]
/root/rel-1.0.0/galaxy/lib/galaxy-1.6.0/priv/hyphy_cnode(erl_eterm_alloc+0xac)[0x101ba1fc]
/root/rel-1.0.0/galaxy/lib/galaxy-1.6.0/priv/hyphy_cnode(erl_alloc_eterm+0x2c)[0x101bb848]
/root/rel-1.0.0/galaxy/lib/galaxy-1.6.0/priv/hyphy_cnode(erl_mk_tuple+0x94)[0x101b88c0]
/root/rel-1.0.0/galaxy/lib/galaxy-1.6.0/priv/hyphy_cnode[0x101baf00]
/root/rel-1.0.0/galaxy/lib/galaxy-1.6.0/priv/hyphy_cnode[0x101bb1bc]
/root/rel-1.0.0/galaxy/lib/galaxy-1.6.0/priv/hyphy_cnode[0x101baf58]
/root/rel-1.0.0/galaxy/lib/galaxy-1.6.0/priv/hyphy_cnode[0x101bb300]
/root/rel-1.0.0/galaxy/lib/galaxy-1.6.0/priv/hyphy_cnode[0x101bb12c]
/root/rel-1.0.0/galaxy/lib/galaxy-1.6.0/priv/hyphy_cnode(erl_format+0x7c)[0x101bb12c]
/root/rel-1.0.0/galaxy/lib/galaxy-1.6.0/priv/hyphy_cnode(query_handler+0x4264)[0x100235fc]
/lib/libpthread.so.0[0xff967f4]
/lib/libc.so.6(clone+0x8c)[0xfde226c]
======= Memory map: ========
00100000-00103000 r-xp 00100000 00:00 0          [vdso]
0fc31000-0fc41000 r-xp 00000000 fd:01 3213       /lib/libresolv-2.5.so
0fc41000-0fc50000 ---p 00010000 fd:01 3213       /lib/libresolv-2.5.so
0fc50000-0fc51000 r--p 0000f000 fd:01 3213       /lib/libresolv-2.5.so
0fc51000-0fc52000 rwxp 00010000 fd:01 3213       /lib/libresolv-2.5.so
0fc52000-0fc54000 rwxp 0fc52000 00:00 0 
0fc64000-0fc68000 r-xp 00000000 fd:01 3214       /lib/libnss_dns-2.5.so
0fc68000-0fc77000 ---p 00004000 fd:01 3214       /lib/libnss_dns-2.5.so
0fc77000-0fc78000 r--p 00003000 fd:01 3214       /lib/libnss_dns-2.5.so
0fc78000-0fc79000 rwxp 00004000 fd:01 3214       /lib/libnss_dns-2.5.so
0fc89000-0fc93000 r-xp 00000000 fd:01 3223       /lib/libnss_nis-2.5.so
0fc93000-0fca2000 ---p 0000a000 fd:01 3223       /lib/libnss_nis-2.5.so
0fca2000-0fca3000 r--p 00009000 fd:01 3223       /lib/libnss_nis-2.5.so
0fca3000-0fca4000 rwxp 0000a000 fd:01 3223       /lib/libnss_nis-2.5.so
0fcb4000-0fcc0000 r-xp 00000000 fd:01 3243       /lib/libnss_nisplus-2.5.so
0fcc0000-0fccf000 ---p 0000c000 fd:01 3243       /lib/libnss_nisplus-2.5.so
0fccf000-0fcd0000 r--p 0000b000 fd:01 3243       /lib/libnss_nisplus-2.5.so
0fcd0000-0fcd1000 rwxp 0000c000 fd:01 3243       /lib/libnss_nisplus-2.5.so
0fce1000-0fceb000 r-xp 00000000 fd:01 3240       /lib/libnss_files-2.5.so
0fceb000-0fcfa000 ---p 0000a000 fd:01 3240       /lib/libnss_files-2.5.so
0fcfa000-0fcfb000 r--p 00009000 fd:01 3240       /lib/libnss_files-2.5.so
0fcfb000-0fcfc000 rwxp 0000a000 fd:01 3240       /lib/libnss_files-2.5.so
0fd0c000-0fe49000 r-xp 00000000 fd:01 3215       /lib/libc-2.5.so
0fe49000-0fe59000 ---p 0013d000 fd:01 3215       /lib/libc-2.5.so
0fe59000-0fe5b000 r--p 0013d000 fd:01 3215       /lib/libc-2.5.so
0fe5b000-0fe5e000 rwxp 0013f000 fd:01 3215       /lib/libc-2.5.so
0fe5e000-0fe61000 rwxp 0fe5e000 00:00 0 
0fe71000-0fe7a000 r-xp 00000000 fd:01 3272       /lib/librt-2.5.so
0fe7a000-0fe89000 ---p 00009000 fd:01 3272       /lib/librt-2.5.so
0fe89000-0fe8a000 r--p 00008000 fd:01 3272       /lib/librt-2.5.so
0fe8a000-0fe8b000 rwxp 00009000 fd:01 3272       /lib/librt-2.5.so
0fe8b000-0fe96000 rwxp 0fe8b000 00:00 0 
0fea6000-0ff49000 r-xp 00000000 fd:01 3211       /lib/libm-2.5.so
0ff49000-0ff58000 ---p 000a3000 fd:01 3211       /lib/libm-2.5.so
0ff58000-0ff59000 r--p 000a2000 fd:01 3211       /lib/libm-2.5.so
0ff59000-0ff5d000 rwxp 000a3000 fd:01 3211       /lib/libm-2.5.so
0ff6d000-0ff70000 r-xp 00000000 fd:01 3202       /lib/libdl-2.5.so
0ff70000-0ff7f000 ---p 00003000 fd:01 3202       /lib/libdl-2.5.so
0ff7f000-0ff80000 r--p 00002000 fd:01 3202       /lib/libdl-2.5.so
0ff80000-0ff81000 rwxp 00003000 fd:01 3202       /lib/libdl-2.5.so
0ff91000-0ffa6000 r-xp 00000000 fd:01 3246       /lib/libpthread-2.5.so
0ffa6000-0ffb5000 ---p 00015000 fd:01 3246       /lib/libpthread-2.5.so
0ffb5000-0ffb6000 r--p 00014000 fd:01 3246       /lib/libpthread-2.5.so
0ffb6000-0ffb7000 rwxp 00015000 fd:01 3246       /lib/libpthread-2.5.so
0ffb7000-0ffb9000 rwxp 0ffb7000 00:00 0 
0ffc9000-

【问题讨论】：

从构建调试信息开始（在构建时添加-g 标志），调用堆栈应该显示文件名和行号。还尝试在调试器中捕获崩溃，并在您的代码中找到它发生的位置，并确保所有值都正常且有效。
与您的问题无关，但更通用的设备：不要将root 用户用于几乎任何事情，至少不要用于开发。
@Someprogrammerdude 它实际上是在嵌入式环境中运行的

标签： c erlang glibc memory-corruption cnode

【解决方案1】：

这可能是什么原因？

最可能的原因是由于程序中某处的错误导致堆损坏。

导致堆损坏的一些错误：写入超过malloced 缓冲区的末尾，freeing 未分配内存，freeing 内存两次，写入悬空（已分配但已经freed 缓冲区）等等等等。

调试此类程序的标准工具是valgrind（不需要重新构建程序）和Address Sanitizer（通常更快更精确，但需要重新构建所有内容）。

【讨论】：