V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
aheadlead
V2EX  ›  C

有无办法知道一个指针指向的内存区域是否为 malloc/calloc 分配的来的?

  •  
  •   aheadlead · 2015-10-16 09:47:54 +08:00 · 1067 次点击
    这是一个创建于 3116 天前的主题,其中的信息可能已经有所发展或是发生改变。
    如题。

    我想过重新封装一次 malloc/calloc/free ,在分配或释放内存的时候,往一个哈希表或者平衡树里面记录。但是感觉这个方法太重,不知道有没有更好的方法?

    谢谢。
    11 条回复    2015-10-16 11:53:32 +08:00
    SPACELAN
        1
    SPACELAN  
       2015-10-16 09:55:44 +08:00
    多分配几个字节,在前几个字节里加标记,然后返回偏移后的地址

    但是感觉这个方法还是不行,有可能冲突
    jukka
        2
    jukka  
       2015-10-16 10:12:06 +08:00
    回答这个问题之前,希望知道你要在这个信息来做什么。
    halfcoder
        3
    halfcoder  
       2015-10-16 10:14:34 +08:00   ❤️ 1
    参考 redis 源码中动态字符串的内存管理实现
    aheadlead
        4
    aheadlead  
    OP
       2015-10-16 11:08:35 +08:00 via iPad
    @SPACELAN 我现在是在这个指针所在的结构体里面加入了一个 bool 变量记录是否是 malloc 得来的。
    @jukka 决定是否要 free 掉

    @halfcoder
    @halfcoder thx 我去看看
    nocwat
        5
    nocwat  
       2015-10-16 11:12:55 +08:00
    看看这个,但并不是特别保险:

    #ifdef WIN32
    return _msize(p);
    #else
    #ifdef __APPLE__
    return malloc_size(p);
    #else
    return malloc_usable_size(p);
    #endif
    #endif
    kzzhr
        6
    kzzhr  
       2015-10-16 11:17:37 +08:00
    刚刚试了试,发现栈区和堆去的地址相差还是很远的。可以在函数开始的时候计算一下各个变量区的地址,然后直接判断。。哈哈。仅供娱乐
    VYSE
        7
    VYSE  
       2015-10-16 11:26:11 +08:00
    直接改导入表里的 malloc 地址到写好的套子里,再封装第三方函数不用你封装后的 malloc 也没有,静态库也得这样改
    shuax
        8
    shuax  
       2015-10-16 11:32:04 +08:00
    malloc/calloc 的区别只是 calloc 自动填 0 ,用完都要 free !!!
    zhicheng
        9
    zhicheng  
       2015-10-16 11:33:52 +08:00
    请自行 Google 内存池。
    jmc891205
        10
    jmc891205  
       2015-10-16 11:49:33 +08:00
    除了 malloc/calloc 你们还有另外的内存分配机制?
    hitmanx
        11
    hitmanx  
       2015-10-16 11:53:32 +08:00
    c++的话重载一下这个类型的 operator new,然后就像你说的弄个哈系表记录一下;或者直接弄个内存池,但是那个也一样重.

    如果在某些系统上你能动态地获得当前 stack 的起始地址和 size limit 的话,应该可以判断哪些是属于栈区的.一般来说 stack 区是从高地址往低地址生长的,heap 区是从低地址往高地址生长的,stack 的地址是要在 heap 的之上的,但这只是一般情况..

    话说这种应用场景我感觉应该是可以通过合理的设计规避掉的,好像在哪里看到过类似的讨论.
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3228 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 00:12 · PVG 08:12 · LAX 17:12 · JFK 20:12
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.