与电围栏库不生效的gcc [英] gcc with electric fence library does not take effect

查看:152
本文介绍了与电围栏库不生效的gcc的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我已经写了有记忆问题时,动态分配一个片段;当 -lefence 选项编译的,似乎没有什么效果。这里是code段:

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;
}

和编译选项:

gcc -g3 -Wall -std=c99 outOfBound.c -lefence

预期的结果是,当执行的a.out 会有后核心转储我分配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 有没有影响?

我也增加了循环上​​限至9日,但仍没有核心转储电动栅栏调用。 (事实上​​的确有默认核心转储,但是这可能是由于 MALLOC_CHECK _ ENV virable因为当我出口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).

更新纳米-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

(我使用的是Debian软件包电动栅栏在Ubuntu 12.04 32位,海湾合作委员会(Ubuntu的/ Linaro的4.6.3-1ubuntu5)4.6。 3

(I am using a debian package electric-fence on Ubuntu 12.04 32bit, gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3)

有关电动栅栏的版本 2.2.4 能被debian(testing分支,即杰西)封装,它作品。

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.

...它必须增加分配的大小来的多
  字长。此外,功能memalign可()和valloc()必须
  兑现在存储器的取向明确规范
  分配,而这一点,以及可以仅通过增加实施
  分配的大小。因此,将在哪些情况
  一个存储器分配的结尾包含一些填充的空间,并且
  访问将不被检测到填充空间的,即使他们是
  超支。

... it must increase the size of the allocation to a multiple of the word size. In addition, the functions memalign() and valloc() must honor explicit specifications on the alignment of the memory allocation, and this, as well can only be implemented by increasing the size of the allocation. Thus, there will be situations in which the end of a memory allocation contains some padding space, and accesses of that padding space will not be detected, even if they are overruns.

尝试超越边界多一点,看看在什么点在超限检测踢。

Try exceed the bounds a bit more, and see at what point the overrun detection kicks in.

这篇关于与电围栏库不生效的gcc的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆