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 的大作中提到】
: 在调一个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 的大作中提到】
: out of memory != memory corruption
| f*****Q
发帖数: 1912 | 4 try jemalloc
【在 g*********s 的大作中提到】
: 在调一个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 的大作中提到】
: 在调一个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 的大作中提到】
: 是in-house的memory pool，处理out-of-memory可能有问题。
: 具体而言，对象分配的时候会越界，同一回收的时候会检查越界情况，然后就报错。当
: 然，代码细节我还没搞清楚，这是观察到的现象。
| g*********s
发帖数: 1782 | 8 发现程序和内存管理模块都有问题。
mem pool这里分配的时候不检查越界肯定不对。
另一方面，跟踪下去，发现根源在于程序里有个模块的数据类型定义的是一个float +
float*的union，然后通过一个bitmap识别。这种数据定义方式也太不爽了。
【在 a****l 的大作中提到】
: 如果是对象分配的时候越界,那就是你们的in-house memory pool lib有bug,你应该去
: 修lib,而不是修你的程序.lib有问题,不管你的程序怎么动,迟早会出现问题的.现在是
: 你调试的时候出问题,你马上可以解决,你应该庆幸你的运气好.你搞高级的memory
: allocation算法 后,可能调试的时候不再出问题了,然后到用户那里,运行三天后某时刻
: 出问题,然后不定时隔几天出次问题,用户肯定把你骂个狗血喷头,然后release版的
: debug也难,用户系统停在哪里老板看着你限时解决你只好看着一堆的01发呆,到那时你
: 才是叫绝望无助呢.
| s******n
发帖数: 876 | 9 都什么年头了, 内存比白菜都便宜了, 还用union, 完全是自虐.
+
该去
在是
时刻
时你
【在 g*********s 的大作中提到】
: 发现程序和内存管理模块都有问题。
: mem pool这里分配的时候不检查越界肯定不对。
: 另一方面，跟踪下去，发现根源在于程序里有个模块的数据类型定义的是一个float +
: float*的union，然后通过一个bitmap识别。这种数据定义方式也太不爽了。
| g*********s
发帖数: 1782 | 10 倒也有需求。是100G，跑50个小时的程序。白菜论吨的话也不便宜。
但我觉得省内存应该有更好的方法。这样牺牲可靠性代价太大。
【在 s******n 的大作中提到】
: 都什么年头了, 内存比白菜都便宜了, 还用union, 完全是自虐.
:
: +
: 该去
: 在是
: 时刻
: 时你
|
|
