g*********s 发帖数: 1782 | 1 在调一个memory corruption的bug。purify/valgrind都没帮上忙,只好一点点跟踪。
目前怀疑的一个方向是动态分配的小型对象(8个字节以下)太多。如果是这种情况,
memory pool的正确处理方法是什么?
如果是保持chunk里特定长度的对象数目不变,那么即使还有很多内存可用,也会出现
out-of-memory问题。
如果允许split其他chunk,那么回收时造成很多碎片,还是会有问题。
研究memory pool的高手指点一下吧。 | m*****e 发帖数: 4193 | 2 out of memory != memory corruption
【在 g*********s 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 在调一个memory corruption的bug。purify/valgrind都没帮上忙,只好一点点跟踪。 : 目前怀疑的一个方向是动态分配的小型对象(8个字节以下)太多。如果是这种情况, : memory pool的正确处理方法是什么? : 如果是保持chunk里特定长度的对象数目不变,那么即使还有很多内存可用,也会出现 : out-of-memory问题。 : 如果允许split其他chunk,那么回收时造成很多碎片,还是会有问题。 : 研究memory pool的高手指点一下吧。
| g*********s 发帖数: 1782 | 3 是in-house的memory pool,处理out-of-memory可能有问题。
具体而言,对象分配的时候会越界,同一回收的时候会检查越界情况,然后就报错。当
然,代码细节我还没搞清楚,这是观察到的现象。
【在 m*****e 的大作中提到】![](/moin_static193/solenoid/img/up.png) : out of memory != memory corruption
| f*****Q 发帖数: 1912 | 4 try jemalloc
【在 g*********s 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 在调一个memory corruption的bug。purify/valgrind都没帮上忙,只好一点点跟踪。 : 目前怀疑的一个方向是动态分配的小型对象(8个字节以下)太多。如果是这种情况, : memory pool的正确处理方法是什么? : 如果是保持chunk里特定长度的对象数目不变,那么即使还有很多内存可用,也会出现 : out-of-memory问题。 : 如果允许split其他chunk,那么回收时造成很多碎片,还是会有问题。 : 研究memory pool的高手指点一下吧。
| h***i 发帖数: 1970 | 5 最好的调memory问题的是totalview,不过要license.
【在 g*********s 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 在调一个memory corruption的bug。purify/valgrind都没帮上忙,只好一点点跟踪。 : 目前怀疑的一个方向是动态分配的小型对象(8个字节以下)太多。如果是这种情况, : memory pool的正确处理方法是什么? : 如果是保持chunk里特定长度的对象数目不变,那么即使还有很多内存可用,也会出现 : out-of-memory问题。 : 如果允许split其他chunk,那么回收时造成很多碎片,还是会有问题。 : 研究memory pool的高手指点一下吧。
| e****d 发帖数: 333 | | a****l 发帖数: 8211 | 7 如果是对象分配的时候越界,那就是你们的in-house memory pool lib有bug,你应该去
修lib,而不是修你的程序.lib有问题,不管你的程序怎么动,迟早会出现问题的.现在是
你调试的时候出问题,你马上可以解决,你应该庆幸你的运气好.你搞高级的memory
allocation算法 后,可能调试的时候不再出问题了,然后到用户那里,运行三天后某时刻
出问题,然后不定时隔几天出次问题,用户肯定把你骂个狗血喷头,然后release版的
debug也难,用户系统停在哪里老板看着你限时解决你只好看着一堆的01发呆,到那时你
才是叫绝望无助呢.
【在 g*********s 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 是in-house的memory pool,处理out-of-memory可能有问题。 : 具体而言,对象分配的时候会越界,同一回收的时候会检查越界情况,然后就报错。当 : 然,代码细节我还没搞清楚,这是观察到的现象。
| g*********s 发帖数: 1782 | 8 发现程序和内存管理模块都有问题。
mem pool这里分配的时候不检查越界肯定不对。
另一方面,跟踪下去,发现根源在于程序里有个模块的数据类型定义的是一个float +
float*的union,然后通过一个bitmap识别。这种数据定义方式也太不爽了。
【在 a****l 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 如果是对象分配的时候越界,那就是你们的in-house memory pool lib有bug,你应该去 : 修lib,而不是修你的程序.lib有问题,不管你的程序怎么动,迟早会出现问题的.现在是 : 你调试的时候出问题,你马上可以解决,你应该庆幸你的运气好.你搞高级的memory : allocation算法 后,可能调试的时候不再出问题了,然后到用户那里,运行三天后某时刻 : 出问题,然后不定时隔几天出次问题,用户肯定把你骂个狗血喷头,然后release版的 : debug也难,用户系统停在哪里老板看着你限时解决你只好看着一堆的01发呆,到那时你 : 才是叫绝望无助呢.
| s******n 发帖数: 876 | 9 都什么年头了, 内存比白菜都便宜了, 还用union, 完全是自虐.
+
该去
在是
时刻
时你
【在 g*********s 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 发现程序和内存管理模块都有问题。 : mem pool这里分配的时候不检查越界肯定不对。 : 另一方面,跟踪下去,发现根源在于程序里有个模块的数据类型定义的是一个float + : float*的union,然后通过一个bitmap识别。这种数据定义方式也太不爽了。
| g*********s 发帖数: 1782 | 10 倒也有需求。是100G,跑50个小时的程序。白菜论吨的话也不便宜。
但我觉得省内存应该有更好的方法。这样牺牲可靠性代价太大。
【在 s******n 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 都什么年头了, 内存比白菜都便宜了, 还用union, 完全是自虐. : : + : 该去 : 在是 : 时刻 : 时你
|
|