问题描述
我写了一段动态分配时出现内存问题的片段；使用 -lefence 选项编译时，似乎没有任何效果.这是代码段:
I have written a snippet that has memory problems when dynamically allocating; when compiled with -lefence option, it seems that there is no effect. Here is the code segment:
int main(int argc, char *argv[])
{
int *a = (int *)malloc(2*sizeof(int));
for(int i = 0; i <=2; ++i){
a[i] = i;
printf ("%d
",a[i]);
}
free(a);
return 0;
}
以及编译选项:
gcc -g3 -Wall -std=c99 outOfBound.c -lefence
预期的结果是当 a.out 被执行时，在 i 被赋值为 2 并且 a[i]=i 之后会有一个核心转储 被调用.
The expected result is that when a.out is executed there would be a core dump after i is assigned to 2 and a[i]=i is invoked.
那么为什么-lefence没有效果呢?
So Why -lefence has no effect?
我还将循环中的上限增加到 9，但仍然没有 electric-fence 调用的核心转储.(实际上默认情况下确实有一个核心转储，但这可能是由于 MALLOC_CHECK_ env virable，因为当我 export MALLOC_CHECK_=0 时，将不再有核心转储).
I have also increased the upper bound in the loop to 9, but there is still no core dump thatelectric-fence invoked. (Actually there is indeed a core dump by default, but this might due to the MALLOC_CHECK_ env virable since when I export MALLOC_CHECK_=0, there would be no more core dump).
UPDATE:nm -A a.out的整体结果如下:
a.out:08049f28 d _DYNAMIC
a.out:08049ff4 d _GLOBAL_OFFSET_TABLE_
a.out:0804864c R _IO_stdin_used
a.out: w _Jv_RegisterClasses
a.out:08049f18 d __CTOR_END__
a.out:08049f14 d __CTOR_LIST__
a.out:08049f20 d __DTOR_END__
a.out:08049f1c d __DTOR_LIST__
a.out:08048718 r __FRAME_END__
a.out:08049f24 d __JCR_END__
a.out:08049f24 d __JCR_LIST__
a.out:0804a01c A __bss_start
a.out:0804a014 D __data_start
a.out:08048600 t __do_global_ctors_aux
a.out:08048480 t __do_global_dtors_aux
a.out:0804a018 d __dso_handle
a.out: w __gmon_start__
a.out:080485f2 t __i686.get_pc_thunk.bx
a.out:00000000 a __init_array_end
a.out:00000000 a __init_array_start
a.out:080485f0 T __libc_csu_fini
a.out:08048580 T __libc_csu_init
a.out: U __libc_start_main
a.out:0804a01c A _edata
a.out:0804a024 A _end
a.out:0804862c T _fini
a.out:08048648 R _fp_hw
a.out:080483b4 T _init
a.out:08048450 T _start
a.out:0804a01c b completed.6159
a.out:0804a014 W data_start
a.out:0804a020 b dtor_idx.6161
a.out:080484e0 t frame_dummy
a.out: U free
a.out:08048504 T main
a.out: U malloc
a.out: U printf
(我在 Ubuntu 12.04 32bit、gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 上使用 debian 包 electric-fence)
(I am using a debian package electric-fence on Ubuntu 12.04 32bit, gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3)
对于 debian 打包的 2.2.4 版本的 electric-fence(测试分支，即 jessie)，它可以工作.
For electric-fence of version 2.2.4 packaged by debian(testing branch, i.e. jessie), it works.
推荐答案
上面的程序在不与电围栏库链接的情况下编译执行后，可以正常运行，不会出现段错误.
Once you compile and execute above program without linking it with electric fence library, it may run without any segmentation fault.
最好将它与电栅栏库链接，然后通过在 gdb 中加载它并给出以下命令来运行它
So better to link it with electric fence library and then Run it by loading it in gdb giving the following command
$ gdb a.out
....
(gdb)run
Starting program: /home/arif/sysprog-2017/processmgmt/nonlocalgoto/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Electric Fence 2.2 Copyright (C) 1987-1999 Bruce Perens <[email protected]>
0
1
Program received signal SIGSEGV, Segmentation fault.
0x000055555555484d in main (argc=1, argv=0x7fffffffe228) at temp.c:8
8 a[i] = i;
因此，从 gdb 的上述输出中，您可以找出导致问题的源行号，如果您此时打印 i 的值，它将是 2 :)
So from above output of gdb you can make out the source line number which is causing the problem if you print the value of i at this instant it will be 2 :)
这篇关于带电围栏库的gcc不生效的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！