2017-04-09 52 views
1

C++程序与分段故障崩溃,当与mcmodel =介质编译。我们在栈上使用了一些非常大的数组,我们需要启用中等mcmodel。 我使用g ++ 5.4时,当我strace应用程序,它打印下面的错误。请告知如何调试。C++当与mcmodel编译程序崩溃=介质

strace ./app 
execve("./app", ["./app"], [/* 65 vars */]) = -1 ENOMEM (Cannot allocate memory) 
--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- 
+++ killed by SIGSEGV +++ 
Segmentation fault (core dumped) 

粘贴可执行 readelf -l应用的readelf输出

Elf file type is EXEC (Executable file) 
Entry point 0x6e4f60 
There are 9 program headers, starting at offset 64 

Program Headers: 
    Type   Offset    VirtAddr   PhysAddr 
       FileSiz   MemSiz    Flags Align 
    PHDR   0x0000000000000040 0x0000000000400040 0x0000000000400040 
       0x00000000000001f8 0x00000000000001f8 R E 8 
    INTERP   0x0000000000000238 0x0000000000400238 0x0000000000400238 
       0x000000000000001c 0x000000000000001c R  1 
     [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] 
    LOAD   0x0000000000000000 0x0000000000400000 0x0000000000400000 
       0x000000000074d0b8 0x000000000074d0b8 R E 200000 
    LOAD   0x000000000074dc50 0x0000000000d4dc50 0x0000000000d4dc50 
       0x00000000000aafe0 0x00000041bf407a08 RW  200000 
    DYNAMIC  0x000000000074dda8 0x0000000000d4dda8 0x0000000000d4dda8 
       0x0000000000000250 0x0000000000000250 RW  8 
    NOTE   0x0000000000000254 0x0000000000400254 0x0000000000400254 
       0x0000000000000044 0x0000000000000044 R  4 
    GNU_EH_FRAME 0x00000000006b2c18 0x0000000000ab2c18 0x0000000000ab2c18 
       0x000000000000ef14 0x000000000000ef14 R  4 
    GNU_STACK  0x0000000000000000 0x0000000000000000 0x0000000000000000 
       0x0000000000000000 0x0000000000000000 RW  10 
    GNU_RELRO  0x000000000074dc50 0x0000000000d4dc50 0x0000000000d4dc50 
       0x00000000000003b0 0x00000000000003b0 R  1 

Section to Segment mapping: 
    Segment Sections... 
    00  
    01  .interp 
    02  .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .plt.got .text .fini .rodata .eh_frame_hdr .eh_frame .gcc_except_table 
    03  .init_array .fini_array .jcr .dynamic .got .got.plt .data .bss .lbss 
    04  .dynamic 
    05  .note.ABI-tag .note.gnu.build-id 
    06  .eh_frame_hdr 
    07  
    08  .init_array .fini_array .jcr .dynamic .got 

内核版本的Linux RK-VirtualBox的4.4.0-64,低延时#85,Ubuntu的SMP PREEMPT周一2月20日12时39分25秒UTC 2017年x86_64的x86_64的x86_64的GNU/Linux的

+0

您是否尝试过使用实际的调试器,比如'gdb'或'lldb'?用'-g'标志编译你的程序,你应该能够精确定位错误的位置。 –

+0

@BenSteffan这不太可能有助于任何事情。看到我的答案。 –

+0

是的,它没有多大帮助,gdb不会显示任何信息。我必须使用strace来查看内核级别发生了什么。 –

回答

0

strace输出你展示表明内核拒绝启动程序(不是一个单一的我你的程序的执行被执行)。

内核简单地说:“这个可执行文件的构建方式让我无法运行”。

readelf -l ./app输出和准确的内核版本可以帮助诊断这进一步。

更新:

第二LOAD段:

LOAD   0x000000000074dc50 0x0000000000d4dc50 0x0000000000d4dc50 
       0x00000000000aafe0 0x00000041bf407a08 RW  200000 

询问内核分配(mmap0x41bf407a08字节。这差不多是263GiB。无论你的机器没有这么大的内存,或者您的ulimit -vulimit -d设置得太低,或两者兼而有之。

+0

感谢您的指点,我粘贴在 –

+0

下的readelf的输出@RavikumarTulugu我已经更新了答案。 –