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\n",a[i]);
}
free(a);
return 0;
}
And the compilation options:
gcc -g3 -Wall -std=c99 outOfBound.c -lefence
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.
So Why -lefence
has no effect?
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: the whole result of nm -A a.out
is as below:
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
(I am using a debian package electric-fence
on Ubuntu 12.04 32bit, gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
)
Update(20140801):
For electric-fence
of version 2.2.4
packaged by debian(testing branch, i.e. jessie), it works.
It is possible you are running into this.
Try exceed the bounds a bit more, and see at what point the overrun detection kicks in.
Once you compile and execute above program without linking it with electric fence library, it may run without any segmentation fault.
So better to link it with electric fence library and then Run it by loading it in gdb giving the following command
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 :)