Valgrind 说“堆栈分配”,我说的是“堆分配”。
我正在尝试使用 valgrind 追踪段错误。我从 valgrind 收到以下消息:
==3683== Conditional jump or move depends on uninitialised value(s)
==3683== at 0x4C277C5: sparse_mat_mat_kron (sparse.c:165)
==3683== by 0x4C2706E: rec_mating (rec.c:176)
==3683== by 0x401C1C: age_dep_iterate (age_dep.c:287)
==3683== by 0x4014CB: main (age_dep.c:92)
==3683== Uninitialised value was created by a stack allocation
==3683== at 0x401848: age_dep_init_params (age_dep.c:131)
==3683==
==3683== Conditional jump or move depends on uninitialised value(s)
==3683== at 0x4C277C7: sparse_mat_mat_kron (sparse.c:165)
==3683== by 0x4C2706E: rec_mating (rec.c:176)
==3683== by 0x401C1C: age_dep_iterate (age_dep.c:287)
==3683== by 0x4014CB: main (age_dep.c:92)
==3683== Uninitialised value was created by a stack allocation
==3683== at 0x401848: age_dep_init_params (age_dep.c:131)
但是,这是有问题的行:
/* allocate mating table */
age_dep_data->mtable = malloc (age_dep_data->geno * sizeof (double *));
if (age_dep_data->mtable == NULL)
error (ENOMEM, ENOMEM, nullmsg, __LINE__);
for (int j = 0; j < age_dep_data->geno; j++)
{
131=> age_dep_data->mtable[j] = calloc (age_dep_data->geno, sizeof (double));
if (age_dep_data->mtable[j] == NULL)
error (ENOMEM, ENOMEM, nullmsg, __LINE__);
}
What Gives?我认为对 malloc 或 calloc 的任何调用都会分配堆空间;这里没有分配其他变量,对吧?是否有可能存在我没有看到的另一个分配(有问题的堆栈分配)?
编辑:我当前的怀疑是堆栈分配的数组:我声明一个指向 double (堆栈)的指针,然后将返回 double * 的函数的结果分配给它。然后我将其移动到之前分配的位置。
我无法 memmove、memcpy 或分配堆栈变量,然后希望它能够持续存在,可以吗?
I am trying to trace a segfault with valgrind. I get the following message from valgrind:
==3683== Conditional jump or move depends on uninitialised value(s)
==3683== at 0x4C277C5: sparse_mat_mat_kron (sparse.c:165)
==3683== by 0x4C2706E: rec_mating (rec.c:176)
==3683== by 0x401C1C: age_dep_iterate (age_dep.c:287)
==3683== by 0x4014CB: main (age_dep.c:92)
==3683== Uninitialised value was created by a stack allocation
==3683== at 0x401848: age_dep_init_params (age_dep.c:131)
==3683==
==3683== Conditional jump or move depends on uninitialised value(s)
==3683== at 0x4C277C7: sparse_mat_mat_kron (sparse.c:165)
==3683== by 0x4C2706E: rec_mating (rec.c:176)
==3683== by 0x401C1C: age_dep_iterate (age_dep.c:287)
==3683== by 0x4014CB: main (age_dep.c:92)
==3683== Uninitialised value was created by a stack allocation
==3683== at 0x401848: age_dep_init_params (age_dep.c:131)
However, here's the offending line:
/* allocate mating table */
age_dep_data->mtable = malloc (age_dep_data->geno * sizeof (double *));
if (age_dep_data->mtable == NULL)
error (ENOMEM, ENOMEM, nullmsg, __LINE__);
for (int j = 0; j < age_dep_data->geno; j++)
{
131=> age_dep_data->mtable[j] = calloc (age_dep_data->geno, sizeof (double));
if (age_dep_data->mtable[j] == NULL)
error (ENOMEM, ENOMEM, nullmsg, __LINE__);
}
What gives? I thought any call to malloc or calloc allocated heap space; there is no other variable allocated here, right? Is it possible there's another allocation going on (the offending stack allocation) that I'm not seeing?
EDIT: My current suspicion is a stack-allocated array: I declare a pointer to double (stack), then assign to it the result of a function that returns double *. Then I memmove it to a previously allocated place.
I can't memmove, memcpy or assign a stack variable then hope it will persist, can I?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我不知道问题是什么,但
可能会帮助您获得有关其抱怨的更多信息;有关详细信息,请参阅此博文:
http:// /blog.mozilla.com/nnethercote/2009/02/27/elimination-undefined-values-with-valgrind-the-easy-way/
I don't know what the problem is, but
might help get you more information about what it's complaining about; see this blog post for details:
http://blog.mozilla.com/nnethercote/2009/02/27/eliminating-undefined-values-with-valgrind-the-easy-way/
可能的原因:
您将
age_dep_data->mtable
定义为double*
但它应该是
double**
才能成为数组的数组possible reason:
you define
age_dep_data->mtable
asdouble*
but it should be
double**
to be an array of arrays我发现这个 valgrind 错误
一直在发生,并且不是错误的根源。自从发布这个问题以来,在我遇到的大多数情况下,这似乎是一个转移注意力的问题。
I have since found that this valgrind error
happens all the time and is not the source of the error. It appears to be a red herring in most cases I've encountered since posting this question.