calloc / free：预读观察 [英] calloc/free: a preplexing observation
问题描述
嗨！
我正在寻找一些关于内存泄漏的答案。
我有一个循环看起来很像这样：
double * largeArray =（double *）calloc（）;
for（...）{
printf（ " iteration＃... \ n"）;
for（...）{
double * foo =（double *）calloc（）;
.....
.....
largeArray [someIndex] =某事;
免费（foo） ）;
}
}
虽然实际代码较大，但它只有20多行
对堆栈变量执行的琐碎数学运算。
很明显，foo不会泄漏，因为它被释放（不，它是
不能在循环之外分配，因为它的大小各不相同。
现在，当我用top监视内存使用时它会相对快速地增长
（外循环每次通过300K），因此应该有一个内存
泄漏。起初我是是的，largeArray是指正在优化，而不是一次性对calloc进行优化，而是按需求，逐页（这将是b b b）但现在我相信可能不是这样的自
" largeArray"是大约4000 * 4000的双倍应该是大约16MB -
我看到>的用法几百次迭代后100MB。
我在i * 86 Linux上使用gcc 3.2.2。
任何猜测都会受到赞赏。 />
谢谢！
鲍里斯
< bo *** @ borisland.com>在消息中写道
news：11 ********************** @ c13g2000cwb.googlegr oups.com ...嗨！
我正在寻找一些关于内存泄漏的答案。
我有一个看起来像这样的循环：
double * largeArray =（double *）calloc（）;
for（...）{
printf（" iteration＃... \ n"）;
for（ ...）{* / double * foo =（double *）calloc（）;
....
....
largeArray [someIndex] =某事;
free（foo）;
}
虽然实际代码较大，但只有20多行对堆栈变量执行的琐碎数学运算才有所不同显然，foo不会泄漏，因为它被释放（不，它不能在循环之外分配，因为它的大小每个时间都有所不同。
现在，当我用top监视内存使用情况时，它会相对快速地增长
（每次通过外循环300K），因此应该有一个内存泄漏。我首先想到的是largeArray。正在优化，而不是一次性调用calloc，而是按需逐页（这将是bizzarre），但现在我相信可能不是这样的，因为
largeArray"是大约4000 * 4000的双倍应该是大约16MB -
我看到使用>几百次迭代后100MB。
我在i * 86 Linux上使用gcc 3.2.2。
任何猜测都会受到赞赏。
我真的没有看到你提供的代码存在问题。
（除了不必要的铸造之外）。它太不完整了。
你能提供全部吗？如果没有，我建议在这里使用valgrind
。但这对于这个新闻组来说不是主题。
-
j
在文章< ; 11 ********************** @ c13g2000cwb.googlegroups .com>，
< bo *** @ borisland.com> ;写道：" largeArray"大约4000 * 4000的双倍应该是大约16MB -
4000 * 4000双打是16M * sizeof（双），如果你有
8字节双倍。
- Richard
2005-01-31 12:18： 44 -0500， bo***@borisland.com 说：
嗨！
我正在寻找一些关于内存泄漏的答案。
[snip]
...自
largeArray以来是大约4000 * 4000的双倍应该是大约16MB -
我看到使用>几百次迭代后100MB。
再次算一算：
4,000 * 4,000
= 16,000,000
如果sizeof（double）为8则：
8B * 16,000,000
= 128,000,000B
a ?? 122 MB
所以你对>的使用100MB似乎与预期的b
一致。
-
Clark S. Cox，III
cl*******@gmail.com
Hi!
I''m seeking some answers about what seems to be a memory leak.
I have a loop that looks much like this:
double *largeArray = (double*) calloc();
for (...) {
printf("iteration #...\n");
for (...) {
double *foo = (double*) calloc();
.....
.....
largeArray[someIndex] = something;
free(foo);
}
}
Though the actual code is larger, it only differs in 20+ lines of
trivial math performed on stack variables.
Clearly, foo cannot be leaking since it''s being freed (and no, it
cannot be allocated outside of the loop, since its size varies each
time.
Now, when I monitor memory usage with top it grows relatively quickly
(300K per pass over the outer loop), thus there ought to be a memory
leak. At first I thought that the "largeArray" was being optimized not
to calloc all at once, but rather on demand, page by page (which would
be bizzarre) but now I believe that might not be the case since the
"largeArray" is about 4000*4000 of double which should be about 16MB -
and I see usage of > 100MB after a few hundred iterations.
I''m using gcc 3.2.2 on i*86 Linux.
Any guesses would be appreciated.
Thanks!
Boris
<bo***@borisland.com> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.com...Hi!
I''m seeking some answers about what seems to be a memory leak.
I have a loop that looks much like this:
double *largeArray = (double*) calloc();
for (...) {
printf("iteration #...\n");
for (...) {
double *foo = (double*) calloc();
....
....
largeArray[someIndex] = something;
free(foo);
}
}
Though the actual code is larger, it only differs in 20+ lines of
trivial math performed on stack variables.
Clearly, foo cannot be leaking since it''s being freed (and no, it
cannot be allocated outside of the loop, since its size varies each
time.
Now, when I monitor memory usage with top it grows relatively quickly
(300K per pass over the outer loop), thus there ought to be a memory
leak. At first I thought that the "largeArray" was being optimized not
to calloc all at once, but rather on demand, page by page (which would
be bizzarre) but now I believe that might not be the case since the
"largeArray" is about 4000*4000 of double which should be about 16MB -
and I see usage of > 100MB after a few hundred iterations.
I''m using gcc 3.2.2 on i*86 Linux.
Any guesses would be appreciated.
I really do not see an issue with the code you have provided.
(Other than casting where unnecessary). It is too incomplete.
Can you not provide all of it? If not, I would recommend the
use of valgrind here. But that is off-topic for this newsgroup.
--
j
In article <11**********************@c13g2000cwb.googlegroups .com>,
<bo***@borisland.com> wrote:"largeArray" is about 4000*4000 of double which should be about 16MB -
4000*4000 doubles is 16M * sizeof(double), which is 128MB if you have
8-byte doubles.
-- Richard
On 2005-01-31 12:18:44 -0500, bo***@borisland.com said:
Hi!
I''m seeking some answers about what seems to be a memory leak.
[snip]
... since the
"largeArray" is about 4000*4000 of double which should be about 16MB -
and I see usage of > 100MB after a few hundred iterations.
Do the math again:
4,000 * 4,000
= 16,000,000
If sizeof(double) is 8 then:
8B * 16,000,000
= 128,000,000B
a?? 122 MB
So your usage of > 100MB seems to be right in line with what should be
expected.
--
Clark S. Cox, III
cl*******@gmail.com
这篇关于calloc / free：预读观察的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
