应用程序正在无故死亡 怀疑高BSS 如何debugging呢？

我一直在CentOs6.6上成功运行我的应用程序。 最近，硬件（主板和内存）已经更新，我的应用程序正在被杀害，没有任何理由。

[root@localhost PktBlaster]# ./PktBlaster Killed

文件和ldd输出

[root@localhost PktBlaster]# file PktBlaster PktBlaster: ELF 64-bit LSB executable,x86-64,version 1 (SYSV),dynamically linked (uses shared libs),for GNU/Linux 2.6.18,not stripped [root@localhost PktBlaster]# ldd PktBlaster not a dynamic executable

strace的输出

[root@localhost PktBlaster]# strace ./PktBlaster execve("./PktBlaster",["./PktBlaster"],[/* 30 vars */] <unfinished ...> +++ killed by SIGKILL +++ Killed

GDB

有没有任何工具来调查堆内容？

双socketsvs单sockets内存模型？

Linux内存pipe理开销

如何打印进程在C中使用的内存的每个字节？

检查Windows下Python程序的最大内存使用情况

[root@localhost PktBlaster]# gdb PktBlaster (gdb) break main Breakpoint 1 at 0x43d664: file VTP.c,line 544. (gdb) run Starting program: /root/Veryx/PktBlaster/PktBlaster During startup program terminated with signal SIGKILL,Killed.

在debugging时，观察到bss内存很大（〜6GB）。 该系统有4GB内存，我认为这可能是问题的原因。

[root@localhost PktBlaster_1Gig]# size build/unix/bin/PktBlaster text data bss dec hex filename 375551 55936 6747541120 6747972607 19235e3ff build/unix/bin/PktBlaster

该应用程序包含许多.h文件和许多数据结构，所以我很难确定为什么BSS被提升到6GB。

任何人都可以请build议如何确定哪个文件造成这个？ 或者其他更简单的方法来debugging呢？

进程的虚拟地址范围

如何在C ++中获取进程的起始/基地址？

有没有办法在运行Linux或Windows的台式机上“testing”C语言中“volatile”关键字的使用？

有一个命令，我可以打电话打印出malloc数据结构？

Windows可执行文件的映射文件可以写入吗？

看来这个问题真的是巨大的BSS大小。 我要求您在注释中显示LD_DEBUG=all /lib64/ld-linux-x86-64.so.2 /path/to/exe的输出。

/lib64/ld-linux-x86-64.so.2是运行时链接程序，在execve系统调用期间，OS用它在进程内存中加载你的二进制文件。 运行时链接器负责解析可执行文件格式，将所有节和依赖关系加载到内存中，执行所有需要的重定位等。 将环境变量LD_DEBUG设置为全部，我们指示运行时链接程序生成调试输出。

[root @ localhost PktBlaster]＃LD_DEBUG = all /lib64/ld-linux-x86-64.so.2 / root / Veryx / PktBlaster / PktBlaster 851：file = / root / Veryx / PktBlaster / PktBlaster [0]; 生成链接映射/ root / Veryx / PktBlaster / PktBlaster：加载共享库时出错：/ root / Veryx / PktBlaster / PktBlaster：无法映射零填充页面：无法分配内存

在运行时链接程序的源代码（glibc-2.17 elf / dl-load.c，lines〜1400）中搜索此错误消息，我们看到：

1393 if (zeroend > zeropage) 1394 { 1395 /* Map the remaining zero pages in from the zero fill FD. */ 1396 caddr_t mapat; 1397 mapat = __mmap ((caddr_t) zeropage,zeroend - zeropage,1398 c->prot,MAP_ANON|MAP_PRIVATE|MAP_FIXED,1399 -1,0); 1400 if (__builtin_expect (mapat == MAP_Failed,0)) 1401 { 1402 errstring = N_("cannot map zero-fill pages"); 1403 goto call_lose_errno; 1404 }

dl-loader正在加载BSS段，通过优化以二进制格式存储，只是字节数，必须初始化为零。 Loader试图通过mmap零初始化的内存块（MAP_ANONYMOUS）分配并从操作系统中获取错误：

15 #define ENOMEM 12 /* Out of memory */

从man 2 mmap：

ENOMEM没有内存可用，或者进程的最大映射数量已被超出。

所以似乎无论什么原因，操作系统无法满足加载程序对内存的请求。 或者使用一些限制（systemd，进程限制，一些安全的LKM，不管），还是内核中没有足够的空闲内存。

确定什么目标文件生成BSS的大部分 – 使用

objdump -j '.bss' -t *.o